Below follows a suggested agenda for the sprint. It's free for anybody to put new items below. The actual contents and order for the agenda will be decided at the sprint. Please also indicate who is behind a certain suggestion. If you are interested in something that has already been proposed and want to add your opinion, then add your name to the list.
- 1 Presentations
- 2 BoFs
- 3 Projects
- 4 Discussions
Presentations of things interesting to the Calligra community. Please state targeted audience.
Short introduction to Friedrich's Kasten framework (possible stone pit for new fundamental Calligra document framework)
The Kasten framework is not yet ready for usage outside Okteta, but has a few things which could be copied already
For everybody with theoretical interest in module-oriented architectures
Calligra on other platforms (Boudewijn)
We have been building and packaging Calligra on Windows for some time now. This presentation will show what we have achieved and highlight the particular problems that need to be resolved if we want to gain more uptake. I'll also touch on the situation on OSX and present some ideas on making life easier.
- Add your presentation here
Kexi (virtual) BoF
Update on status of the Words Bibliography based on CalligraDB:
- CalligraDB is a lib moved in 2.6.0 from KexiDB to libs/ in order to enable reuse by Calligra apps
- People involved: jstaniek (CalligraDB), smitpatel (biblio), boemann (Words maintainer)
- Details at Kexi/KexiDB/libCalligraDB
- Only minimal changes have been made to KexiDB
- Words 2.5 used QtSql lib
- Words 2.6.0 switched to CalligraDB
- Plans for 2.6.2: fix data very inefficient way of data retrieval (O(n^2) CPU cost)
- To do so, some code have to be moved from Kexi, as agreed with smitpatel
- As a result, data will be cached on retrieval, allowing proper editing and filtering filtering
- The data will be put into a table model (Qt Model/View) as needed by Words' GUI
Proposal of Modern/Awesome User Experience for Calligra:
KOffice was built around kparts. KParts were used for three things:
- to select the right koffice plugin to open a document from KoApplication
- to embed documents in documents
- to show documents in other kpart-enabled applications like konqueror
3. no longer works. 2. has been replaced by flake. 1. is giving us a lot of grief -- for instance, when a calligra application cannot show its config menu in the startup screen because the application's part actually hasn't been loaded, or when we need to create a whole part with everything to load a document in a filter, or when we want to show more than one document in one main window.
We already started to split KoDocument and KoPart, but I'm no longer convinced that that was the right solution. I think we need a deeper refactoring and remove the calligra-internal use of kparts completely. If, at some point, we create a kpart for an application for integration with, say, konqueror, then that is fine, but it should not be the way calligra works internally.
Boud's set of requirements for a new framework for calligra:
- needs a separation between document, view, mainwindow and application
- The document is only responsible for loading, saving and keeping the data.
- The view is repsonsible for painting the document
- The mainwindow is responsible for showing a gui: menu's, toolbars, actions -- it is more or less the controller
- The application manages views, documents and windows. A document can be in more than one view, a mainwindow can show more than one view and more than one document.
These concepts need to be abstract, so we can create different views, mainwindows and applications for different purposes (like a KDE, QML or a Qt based application, or a KPart for embedding in other kde apps).
Boud has been playing around with some test code of my own and has investigated Friedrich's kasten framework (part of okteta). I think kasten is basically suitable for Calligra, but might need extension: it does do the separation between document, view, window and application already at least.
Boud wants to start with krita and then move other apps to the framework as needed.
How to make Calligra ready for QML based applications
Currently it is not possible to build calligra without support for QWidget. However it would be nice to have that so it is easy to build apps with only support for QML. That might mean we should have a backend which is not using KDE libs to heavily or only onlce KDE frameworks come available.
This BoF is about discussing where we want to go. And how it might be archived. It is partly related to the KParts BoF.
Using cstester and friends for testing
Show how to setup cstester environment and and how to use it for testing calligra.
Let's sit together for an hour and go through all review requests. (Boudewijn)
- selection and masks
- Krita sprint
- foundation matters
- Grayscale Selections
- which CS to use? (gray, gray+alpha)
- what way Gradient and Fill tools should handle that?
- Recenter of the view after transformation of the image
- Future of Bumpmapping?
- ideas for "real paint" emulation brushes
- colorspaces for the "height" channel. how to implement?
- Ideas and status of GSoC for Krita
- Probably, we need to schedule some work for filters system. David Revoy said he used Gimp for postprocessing only. Do we need to work toward eliminating Gimp from the workflow or we need to concentrate on other topics?
- Action system
- UI separation, QML and Macro integration
- Integrate with input manager?
- Organization of action code, relation with strokes framework
- Code in plugin vs ui/
- Krita Sketch merge?
Saving MS formats
One of the biggest weaknesses of Calligra right now is the inability to write MS formats, especially in professional settings. We would like to investigate how we can create an embryo for a DOCX export filter so that we can work on individual features once we are back home.
The filter embryo should be able to do the following things:
- create an empty docx file from and empty odt file.
- convert the most common attributes of text styles
- convert running text (paragraphs, spans)
This BoF will outline a plan for this and maybe even do some initial hacking (thus making it a "project" as seen below and not just a BoF).
"Add your BoF here"
Projects we'll work on in small groups, mostly coding or creating other concrete results.
Fine-grained configuration of buildsystem, with easy customisation for target products and target features
- Add your project here
Discussions about topics, which are relevant to all or a sub group of people. Please state audience and desired result of the discussion.
Future of Calligra Active
- Next must-have features
- Have same app for everything or separate apps for each corressponding Calligra App?