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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
