________________________________________
From: development-bounces+alexander.blasche=theqtcompany....@qt-project.org 
<development-bounces+alexander.blasche=theqtcompany....@qt-project.org> on 
behalf of Thiago Macieira <thiago.macie...@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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to