Calligra/Meetings/Spring 2013 Sprint/Agenda: Difference between revisions

From KDE Community Wiki
Line 14: Line 14:


=== BoFs ===
=== BoFs ===
* Fill in topics here...


====Kexi (virtual) BoF====
====Kexi (virtual) BoF====
Line 38: Line 36:
*how
*how
*when
*when
====Replacing KParts====
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.
===="Add your BoF here"====


=== Projects ===
=== Projects ===

Revision as of 01:13, 23 February 2013

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 is already proposed and want to add your opinion, then add your name to the list.

Presentations

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

  • Add your presentation here

BoFs

Kexi (virtual) BoF

Note

No Kexi developer will be physically present, but content with updates is here anyway


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 buy Words' GUI


Proposal of Modern/Awesome User Experience for Calligra:

  • what
  • why
  • how
  • when

Replacing KParts

KOffice was built around kparts. KParts were used for three things:

  1. to select the right koffice plugin to open a document from KoApplication
  2. to embed documents in documents
  3. 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.

"Add your BoF here"

Projects

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

Discussions about topics, which are relevant to all or a sub group of people. Please state audience and desired result of the discussion.

Add your discussion topic here