Month: September 2009

I’ve been unwell the last couple of days, and with a muzzy head programming isn’t that easy. So I decided to try out gnome-shell and document some of my initial findings. The following finds are purely subjective and my own opinions only. Comments are welcome telling me I’m being a moron, or that an issue is fixed in a newer release. I’m currently using the newest packages in Fedora rawhide.

• In general, everything seems slower. The animations are a nice touch initially, but I find they actually slow down my workflow. I’m not the sort of person that likes compiz for this reason either.
• I’ve not got a window list anywhere, so I find I’ve got about 40 nautilus “Home” windows open at any one time.
• I use a dual screen, and quite a lot of the UI appears centered in the virtual screen, which is not that nice when one panel is slightly different size to the other, with about 2 inches between them. For instance for  the time, one panel has “Wed 10” in the top right, and the other panel has “22 AM” in the top left. Also, totem when watching a movie seems to be put halfway between each workspace in the preview screen, but appears on neither side of the workspace if you click on it. There are 4 or 5 different UI bugs that I need to research and file.
• I really don’t see the point in having a giant top bar with only the current running application on it, and the time. Seems a giant waste of space. I also don’t think it needs to be on across all screens on a multi-monitor display.
• I often use the dual screen to display two documents at once, if I’m comparing photographs or looking at code and a debugger. Every time I go back to the preview menu screen I’m forced to choose a single window, and other windows get arranged and stacked seemingly randomly.
• I can’t seem to click on the status area icons when in the sidebar mode. This seems an artificial limitation.
• There isn’t a way to clear the recent documents list, so if I’m working on a confidential document with a sensitive filename, I can’t show anyone my menu or take a screenshot (which I wanted to do for this blog entry…)
• I can’t find any way of getting access to the preferences menu items (e.g. to change my mouse acceleration), other than typing in “mouse” into the search bar, which didn’t exactly seem intuitive.
• Black menus and notifications are not really my colour, and I couldn’t find a way to chose anything else.
• There appears to be no configuration at all. I know tweaking things is the devils work, but no configuration allowed at all?

So, it’s certainly very different to what we’ve had before, but you can clearly see it’s a preview, not a final release. It’s certainly not useful to me as a production desktop just yet.

Every time somebody writes “Linux is about choice” something inside of me dies. Just because something can be done, doesn’t mean it should be done.

For the last couple of weeks I’ve been re-writing the existing PackageKit-glib bindings. The old library was beginning to limit what we could do with client applications. The biggest problems were:

• A lot of the dbus calls are sync, which slowed down application startup and user input “snappyness”
• A lot of the methods were not cancellable
• It’s very hard to add details and update details about a set of packages, without caching all the data in the client
• Having to “reset” a single heavyweight client instance before doing each operation (mitigated in some respects with PkClientPool)

As the days have progressed, I’ve slowly add more functionality to the packagekit-glib2 library, with the aim of removing the original glib library for 0.6.x. After two weeks of hacking, I’ve deprecated the glib1 library, with everything in the PackageKit git master tree is now using glib2. Overall, working with everything asynchronous works really well. The GUI clients benefit the most, although it makes the text clients much simpler too:

[hughsie@hughsie-laptop client]$ wc -l pk-console*.c

 2580 pk-console-glib1.c

 1625 pk-console-glib2.c

One of the main benefits is that the “dance” (the multiple transactions) can be done asynchronously, and completely hidden from the client. To do this, I’ve got the following classes:

• PkControl: For getting properties on the main interface, and doing methods such as GetTid
• PkClient: For scheduling a single transaction
• PkResults: For storing the completed results of the transaction (packages, update-details, all the compound objects)
• PkProgress: For storing current progress, for passing to async clients
• PkTask: For managing the “dance”, for instance, requeuing transaction for simulate, gpg-keys, eulas and for trusted. It superclasses PkClient.

Now, PkTask on it’s own isn’t very interesting, as it fails at every step of the dance by default. PkTask does however have klass methods that can be overridden by classes implementing PkTask. There’s an example I made for the “make check” functionality called PkTaskWrapper which basically accepts each step of the dance without asking the user. More interestingly, there’s a class called PkTaskText that implements PkTask and handles all the callbacks using console commands like fgets. That’s what text stuff like pkcon and pk-debuginfo-install are now using, and why they are a lot smaller now.

This means that pkcon can create an instance of PkTaskText, and all the interactions are done for it in the PkTaskText object. The actual interaction is hidden from pkcon, and all it gets is the progress callback as the transactions are scheduled. And because PkTaskText can be used as a PkTask, it can also be used as a PkClient, so the methods that are not wrapped can be used with a single object. It also means that other clients can just use PkTaskText and get all the complex interaction stuff handled automatically.

Of course, in gnome-packagekit, it will make things much cleaner as each PkClient can be converted to use an async GpkTask, which will handle all the interactions. So, instead of having all the scary logic about what methods to send in response to different signals and return codes in multiple places, we can just derive from PkTask and do them all in one place. Of course, moving from a 80% sync library to a 99% async library is going to be hard for projects that make heavy use of libpackagekit-glib. The most obvious example is gnome-packagekit, and so far I’m already about 80% they way through. Diffstat reports “59 files changed, 6311 insertions(+), 8684 deletions(-)” with the majority of porting work just switching code to use the async variants. When it at least compiles I’ll push it to git master, but until then it lives in the glib2 git branch.

The new code is much cleaner, more debuggable and most of all supportable, so when 0.6.x is released (a few months away) we can remove a metric ton of code (~20000 LOC) from the server. In preparation we’ve written a porting guide, although it’ll get more love when the design for packagekit-glib2 is set in stone.