kdesupport/polkit-qt question

[Kevin Krammer]

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 
API.

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 
integration.

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.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090311/12cda54c/attachment.sig>