Jump to content

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

From KDE Community Wiki
Zachmann (talk | contribs)
Halla (talk | contribs)
Line 69: Line 69:
====Using cstester and friends for testing====
====Using cstester and friends for testing====
Show how to setup cstester environment and and how to use it for testing calligra.
Show how to setup cstester environment and and how to use it for testing calligra.
===="Reviewboard backlog"====
Let's sit together for an hour and go through all review requests. (Boudewijn)
===="Krita Bof"====
Topics:
* selection and masks
* Krita sprint
* foundation matters


===="Add your BoF here"====
===="Add your BoF here"====

Revision as of 09:38, 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.

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.

"Reviewboard backlog"

Let's sit together for an hour and go through all review requests. (Boudewijn)

"Krita Bof"

Topics:

  • selection and masks
  • Krita sprint
  • foundation matters


"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.

Future of Calligra Active

Add your discussion topic here