kevin.krammer at gmx.at
Wed Mar 11 20:00:36 GMT 2009
On Wednesday 11 March 2009, dantti85-dev at yahoo.com.br wrote:
> Hey Kevin,
> The issue is that some polkit methods included
> in libpolkit-dbus and libpolkit-grant requires
> you to pass DBusConnection and DBusMessage.
From the names I would assume that libpolkit-dbus is some kind of convenience
API for developers who don't have access to high level D-Bus bindings and
build-time/run-time code generation.
A bit like libhal for HAL. Nice for the poor C coders who cannot get high
level data structures and methods auto-generated, unnecessary for Qt
developers who can get C++ classes generated by qdbusxml2cpp, useless for
Java/Python/Ruby/C# developers who have insanely easier methods of accessing
D-Bus but extra effort for calling into low level C code.
No idea what the other library is about but since there is already a D-Bus
specific library, it shouldn't have any D-Bus inside it, even less in its
I would consider that broken by design if it does, unless is sole purpose is
to be used on top of the other for even more convenience.
> It's not that we didn't try to avoid but we can't
> get a QDBusMessage and pass it, it's not simply
> implementing or fixing an interface.
If its doing D-Bus, it is almost certainly sending D-Bus method calls to some
D-Bus interface on a D-Bus object path on a D-Bus connection name.
So it either installs the D-Bus introspection file or is runtime
introspectable (which in turn can be saved to a file, but since this is
about "standard" infrastructure, the former is way more likely).
So it is possible to generate a native Qt implementation using qdbusxml2cpp.
So instead of having to deal with something that has never been intended to be
used by application developers (libdbus API), or manually coding QDBusMessage
based calls, you get directly callable C++ code.
> The only way to avoid that would be to reinvent
> both libpolkit-dbus and libpolkit-grant which
> imo is a waste of time.
I'll need to have a better look at it, but it sounds a bit like the libraries'
authors should probably thing about separation of concerns.
> I hope this can clarify the matter, or maybe
> i don't get exactly what you meant. :D
And I might not understand the purpose of each of the involved components.
It just feels like some grand hack around the tool stack's actual D-Bus
Writing all that event loop integration code again must have been lots of
work. I remember having to fix the one I had in the Qt3 bindings several
times. All those watches and timeout callbacks are quite tricky.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel