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.
_______________________________________________
calligra-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/calligra-devel
