The development of Qt frontend for PackageKit produced first visible results in form of a working GUI. In the meantime, the library for Qt itself was rewritten to use D-BUS.
Richard Hughes posted the first screenshot of the Qt gui for PackageKit:
A public git repo can be found at git clone git://people.freedesktop.org/~hughsient/QPackageKit. At the same time the Qt bindings have been reworked:
Kevin Krammer, a KDE developper. […] said that using the DBus interface would be cleaner and would make it easier for KDE devs to use the lib. […] I started the bindings again, from scratch, using the DBus interface.
With such a library chances might be realistic that one day a PackageKit GUI becomes a full member of KDE 4.x and will be shipped with it by default. Many backends are supported already by PackageKit, and others are coming in the near future: OpenSuse plans to implement support as well:
> Are we going to want to use PackageKit for
> Package Management as well?
Yes, as it provides an easy (and community driven) way to make ‘role based’ systems management happen.
/home/liquidat 
I think the KDE community should thank Richard for making PackageKit accessible through DBUS. The previous method required including glib headers in KDE apps, which would have bloated memory because KDE/Qt already has a low-level library: QtCore. Communicating over DBUS is a much cleaner method, and that’s why KNetworkManager/NetworkManager and Solid/Hal chose DBUS.
1. Great!
2. But really, they could at least have tried to find some remotely appealing name. Even PackageQt, Installator or a plain “Package Management Software” would be more sensible than the dumb old QMySoftwareName scheme. Especially since (as with NetworkManager) the GTK+ frontend hasn’t got any other name than that of the backend… I totally hate this sort of second-class citizenship.
woo 🙂
as soon as it’s got the ability to do ‘apt-get install’, I wanna try it. packagekit is a great idea that really should’ve been done sooner.
Using D-Bus means using an extra process and slow inter-process communication though. 😦 In Fedora, and I guess in several other distributions too, all Qt/KDE 4 apps are linking against GLib anyway because Qt 4 is built with GLib event loop support.
I think PackageKit always used D-Bus, since this offloads the privilege separation, i.e. the user program separated from the packagekit process through the system bus.
I basically recommended that the Qt API should use the D-Bus interface directly rather than wrapping the C-Wrapper.
Doesn’t make sense to first map the D-Bus semantics into C and then map it again into C++/Qt, especially not when doing your own D-Bus wrapper is mostly handled by a code generator anyway.
@Chani: The apt support is very basically atm because the backend has been reworked entirely afaik. But it is just a question of time until it works with apt, I guess.