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.
November 14, 2007 at 20:28
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.
November 14, 2007 at 23:36
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.
November 15, 2007 at 7:27
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.
November 15, 2007 at 11:29
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.
November 15, 2007 at 11:43
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.
November 15, 2007 at 12:44
@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.
November 16, 2007 at 10:31
[...] | liquidat] PUBBLICITÀ PUBBLICITÀ (1 Voti | Media: 5 su 5) 0 [...]