Making dbus optional in Calligra

[Sebastian Sauer]

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 :)

> What would be even cooler than a compile-time switch, though, would be 
> to make dbus support a plugin in all our applications, so we can just 
> not compile/install that plugin when we
> don't want dbus.
>
> That can't be hard, I'm thinking, since most dbus usage is simply a 
> kind of wrapper around the view classes.
>

pro plugin;
* Clear separation at runtime making it easy to keep code-paths working 
in the future. A killer.
* Someone can enable/disable them even later. Nice to have but not 
really a killer.

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.
* We need to handle the case that a plugin uses the adaptors. That is 
for example the case for the scripting plugins. A plugin cannot access 
another plugin so we need some mechanism (e.g. interfaces) to let them 
communicate/access each other.
* We maybe need to export more classes/functions so the dbus-plugin can 
access them.
* We may need more then one plugin since it's not only the apps but also 
libs (which is shared among the apps) that implements dbus-adaptors. 
That sounds like we would either need to create a dbus-lib in 
calligra/libs that the dbus-plugins link against or we need to make sure 
that loading the app-dbus-plugin also loads the libs-dbus-plugin (the 
later should be easy to achieve).
* Those changes are *way* more offensive then adding a bunch of #ifdef's

Personally I tend to the compile-switch.

> Boudewijn
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>