On 7 February 2012 20:41, Sebastian Sauer <[email protected]> wrote: > On 02/07/2012 08:25 PM, Marijn Kruisselbrink wrote: >> >> On Tuesday, February 07, 2012 07:59:55 PM Sebastian Sauer wrote: >>> >>> On 02/07/2012 02:52 PM, Boudewijn Rempt wrote: >>>> >>>> On Tue, 7 Feb 2012, Sebastian Sauer wrote: >>>>> >>>>> What I would like to do is to introduce in Calligra a way to >>>>> completely disable any use of dbus. The target would be to 1) make >>>>> Calligra compile with #define QT_NO_DBUS and 2) make Calligra >>>>> optionally compile without support for dbus even if Qt-dbus is >>>>> available. >>>>> >>>>> The idea is to address one of the issues named by Mek in his amazing >>>>> blog-post about the port of Calligra to Android ( see >>>>> http://blogs.kde.org/node/4521 ). The issue is that Android does not >>>>> ship with dbus. >>>>> >>>>> The idea would be; >>>>> 1. introduce a new cmake flag that allows to disable dbus Caligra >>>>> wide. Per default dbus is enabled except Qt was compiled without >>>>> support for it. >>>>> 2. introduce #ifdef's all over Calligra to proper disable / not >>>>> compile any code that makes use of dbus when dbus was disabled. >>>>> >>>>> Good idea? What do you think? >>>> >>>> Well, Mek is the expert, but I guess it would help -- though the >>>> biggest issues with dbus are actually in kdelibs. >>> >>> kde-frameworks addresses lot of them. In fact there are very few places >>> Calligra links against that depend on dbus. KMimeTypeTrader and >>> KParts/KPartsPlugin/KLibLoader are the only big things left but that's >>> todo for later. Let's first look at dbus :) >> >> That calligra doesn't need dbus is quite obvious of course from both the >> N9 >> documents app and my android efforts. In both cases there are no other kde >> daemons around/no dbus communication going on, and both work just fine. >> (the N9 >> version is of course still built against libqtdbus). Removing the dbus >> dependencies from calligra was indeed mostly trivial, I think >> 911bda03c72d8bf488166beeb1b3ad36a61842ea >> 1e146dd026e5b5a7d85e91f109c222b2369a9665 and >> 2a71dacf4b7b30af8a0138624c7565722f21f7df have most of the changes I had to >> do >> for that (there might be some minor changes in some of the other commits >> in >> the mobile-android-mek branch, but those are the main ones). Those commits >> are >> currently disabling dbus code based on if it is an android build, but it >> would >> of course be rather trivial to do that based on some other parameter. > > > Yes, I was planing to "reuse" the work done by you in the branch. So, yes, > it's a try to get the first part of your work into master :) > > >>> contra plugin; >>> * We need to handle dbus-registration. That means if for example a sheet >>> is added in Calligra Tables then the dbus plugin needs to be notified so >>> it can create a SheetAdaptor. The same is true for *ALL* signals a >>> dbus-adaptor exports. That means we need interfaces/decorators in Tables >>> to forward calls to the plugin's or some other way to proper notify the >>> plugin when something happens. KParts and flake are clearly not enough >>> here. >> >> At least for the calligra tables case, there is no extra code needed in >> tables. The only dbus related code that I had to ifdef out there is the >> creation of the MapAdaptor/SheetAdaptor instances, all the rest is handled >> in >> those classes based on signals that are already exposed anyway. > > > Not in the case of #ifdef's but in the case of a plugin we *need* extra-code > so the adaptors can live and work outside of tables within a tables plugin. > So, yes, that confirms my tendency for the #ifdef solution cause it's just > more clean / less intrusive then moving all the dbus-logic to plugins.
Plus: for plugin to be really a plugin we have to go for another round of package splitting... what may be not like a dream work when the use cases are this ephemeral. -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) KDE Software Development Platform on MS Windows (windows.kde.org) _______________________________________________ calligra-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/calligra-devel
