[Development] Enabling of QtDBus in Qt 5.4 and 5.5

[Blasche Alexander]

________________________________________
From: development-bounces+alexander.blasche=theqtcompany.com at qt-project.org <development-bounces+alexander.blasche=theqtcompany.com at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>

>Clarifying after question on IRC: will be enabled by default for all builds on
>all OS. Unless you pass -no-dbus, of course.

What's the runtime call that let's me determine what the state of the dbus union is on the system?

So far there are two cases:

1.) no dbus (nice qmake check to cut for Windows, Android and some other platforms)
2.) dbus available but no daemon or permission issues (QDbusConnection::connectToBus(...).isConnected())
3.) all working and enabled

Consequences of eventual 5.5 changes:

- Now I cannot use point 1. above anymore to compile dbus backends out on platforms where DBus is useless anyway. That's doable by emulating your platform specific enabler in my own modules of course. I guess this is just convenience which I lost.

- Case 2 above is even further overloaded. How do I distinguish the no-daemon case from permission issues from dlopen failures. Any new API calls for that? This is especially important when you don't want to do the "compile dbus out on win" checks in qmake. Do I have to duplicate your dlopen() attempt to figure that out? How about a "QDBusConnection::platformSupportsDbus()" call?

Personally, I think it is rather useless to enable QtDBus on for example Windows. Yes, its better cross-platform programming and there are some esoteric guys/projects who use dbus at this stage on Windows. However the default setting to enable it for the esoteric use case means you ship tons more code for nothing. Alternatives might have been to only enable it when specifically requested only (aka change your configure2 option to disabled on windows if no dbus option passed) or even compile the lib against some no-op code (which would satisfy the true cross platform development use case). I guess you might argue that QtDBus is not that large but without more strict qmake changes you may create more code to be shipped in other modules/projects too.

What were your reasons/motivation?


--
Alex