Making dbus optional in Calligra

[Marijn Kruisselbrink]

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.


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


Marijn