Making dbus optional in Calligra

[Sebastian Sauer]

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.