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