Calligra 3.0 for Qt 5.1?

[Boudewijn Rempt]

On Monday 29 July 2013 Jul 21:57:11 Dmitry Kazakov wrote:
> Hi, Boud and all!
> 
> I cannot tell much about the details of the porting, but I'd like to add
> two thoughts:
> 
> 1) Our master is currently in releasable state, which is exactly what we
> wanted to achieve a couple of sprints before. I think we shouldn't drop
> this achievement. I should admit that many painters use the script by
> David, which also depends on master branch. It might be not very easy to
> explain all the people to switch branches while using the script (yeah, we
> have such experience with compiling Vc 0.7). With breaking master by the
> porting work, Krita Lime releases will not be possible anymore. At least we
> will need a special branch for backports and we will have to maintain it,
> which is hardly possible.

Yes, that's an important consideration. If we could get master release stable for Qt 5.1 in a month or two, I would argue that we should try that -- make the period of pain as short as possible. But given the amount of unmaintained and barely maintained code we have to drag along, I doubt that that's feasible.

> 2) Dropping KDE Framework completely... well, I know at least one
> regression we will get: we will not be able to Drag&Drop images from
> Firefox, because it drops them as url's, which is currently handled by KIO.

Even though that's fixable, I am sure there will be more places where we would lose some polish or some functionality. On the other hand, it would also mean in many case a simpler codebase. I really would like to take a good, hard look at all the KDE frameworks or libraries and determine whether or not the dependency offers enough functionality -- I really would prefer to make Calligra run as light on dependencies as possible by default..

Especially for the ones that use dbus. Currently, as far as I can tell, dbus offers the following functionality for Calligra:

* check whether an autosave document belongs to another open instance of an application
* remote slideshow management for Stage
* IPC for the kioslaves. I need to check, though, there used to be an effort to make kioslaves run in-process...

> I think this port should currently happen in a separate branch. I will
> personally try to use it for my development and back/forward-port my
> patches between it and master. And I would really like to avoid breaking
> the KIO-based features. Or at least make it configurable by cmake.

kio has another problem, besides dbus and the multi-process model, and that is it's tight coupling to QWidget -- if the functionality kio gives us that users are really using can be simply implemented with a few lines of code, then I would prefer that. D&D from firefox probably is easy to replace, and I really wonder how many users are loading documents using the ftp, fish or http kioslaves on a regular basis.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl