Making dbus optional in Calligra

[Jaroslaw Staniek]

On 7 February 2012 20:41, Sebastian Sauer <mail at dipe.org> 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)