Year: 2010

This week, I’ve spent a bit of time working on a network panel for the new control center. The old network settings configuration dialog allowed you to do everything to anything, and most users (myself included) only touched a fraction of one percent of the functionality, and the complexity of other other controls made the UI very difficult and unintuative to use.

In the design research we’ve looked at what other OS’s do, such as Meego, OSX, etc and have started working on some design mockups. The network control panel will probably change quite a lot in GNOME 3 from what I’m showing here, based on user feedback and designers doing proper mockups. So, onto the interesting bit:

It’s all work in progress, and comments welcome. It’s using NetworkManager as a backend. Woot.

Last week I sat down and implemented some of the gnome-control-center mockups for GNOME 3.

This is the screen mockup, which as the name suggests, is all the settings related to the screen.

We’ve also made the power panel much, much easier to use. All the power-user settings are still available in GSettings, if you’re the geeky sort who likes to tweak. The conclusion we’ve come to, is that we should fix drivers, rather than provide workarounds for hardware bugs in the UI.

This is all available right now if you compile using jhbuild, and will be available in Fedora rawhide soon.

Yesterday I merged a patch to PackageKit which added the UpgradeSystem() method to the transaction interface. This is the natural compliment of the GetDistropUgrades() method which was added last year. This allows a session user to upgrade the OS using the same familiar PackageKit tools, and without doing dumb things like asking for the admin pasword and running GTK and python graphically as the root user.

In Fedora, we use a package called preupgrade. This was created by Will Woods and Seth Vidal in 2008, and I was asked to maintain it last year. I’ve been helped by James Laska, which has been very much appreciated. Preupgrade has been fixed up a few times, but the majority of the code is the same as when I inherited it. Preupgrade was a nearly-good-enough monolithic lump of code that kinda worked.

In my humble opinion, Fedora (and all other distros) are too small to maintain such mission critical stuff such as distribution upgraders. The PackageKit project has shown people that by distributions combining forces, they can share frontends and write different small backends and free up developers for other things. As a team, we have a better quality product than the results of one developer on one distribution.

So I figured preupgrade should have the same love. 99% of the preupgrade code is GUI interface code and this was easily converted to C, and to use PackageKit. The result of this is in gnome-packagekit git master, with a new tool gpk-distro-upgrade.

Don’t go and try this code just yet. None of the preupgrade backend code has been moved to the yum backend, although I don’t assume I’ll have many problems, and plan to do this later in the week. If you want to test this use the “dummy” backend, although this won’t actually perform any changes of course.

Hopefully some of the other distros can play with gpk-distro-upgrade and improve it. Hopefully the translators will file bugs about the bad English, and translate it to 50 languages. Hopefully another distro will port their os updater to use this new functionality and find bugs or speed up the common code a little.

All I know is preupgrade will live on as part of PackageKit, and now it’s targeted at a bigger audience than just the few million of Fedora users.

PackageKit tries really hard to work for these people. PackageKit is designed for these people.

Debconf is a simple protocol that dpkg uses to ask the user configuration data at install time. I think it’s generally a bad idea, as installing should generally be silent and automatic and configuration should be a separate step. That said, PackageKit needs to also work on Debian, as some people seem to really like debconf and are not happy shipping a PackageKit that won’t talk the debconf protocol.

So, last weekend I sat down and wrote the required PackageKit-glib2 patches to make the PackageKit-enabled frontends setup a pipe for use in apt, and to spawn debconf when required. Of course, this is a no-op for things like searching and when a package needs no configuration, but for other packages it blocks (urgh) the transaction and the user gets asked questions. Of course, if the transaction is running non-interactively, then the backend won’t ask any questions at all.

Of course, I’m kinda disappointed someone from Debian didn’t write the patch themselves; with all the blogs, wiki articles and emails about the “lack of debconf support in PackageKit” it would have been less typing to actually write the patch. Hey ho, it’s done now. If you install the recently released 0.6.10, then it “just works” with no re-compiles of any front-end clients required.

Of course, I should also like to thank Daniel Nicoletti and Sebastian Heinlein for development help, and Matthias Klumpp for testing. Thanks.

Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about?

Mo illustrated a few days ago about how confusing the updater is and I agree with her; and it’s mostly my fault for not pushing applications harder. Lists of unlocalized generic packages are so 1990’s, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs.

So, a solution. I’ve been working on app-install with some people from other distros for the last few months, and last week it had it’s first public release. Schema version 2 is already being worked on, and now optionally integrates with PackageKit and also provides some other features like sorting applications by rating and application screenshots. I’ve already generated distro metadata for the entire fedora repository (this takes about four hours on my laptop) and packages are available. It’s really easy to generate metadata for the other repos too, but I digress. Read the README file for all the guts about how it works.

I’ve got two demo applications that use the app-install data. One is an installer and one is an updater. These are work in progress, and show dramatically the lack of my UI design skills.

The installer will be an additional tool (much like the ubuntu-application-installer compliments synaptic) which is focused on ordinary desktop users. If you know what an epoch is, it’s probably not for you. The old tool will remain, so panic not. This tool will just install applications, that-is anything that ships a desktop file with an icon. Anything else just isn’t shown. Sorry! We will hopefully show groups too, perhaps even the same entries as the “Applications” menu.

The updater will be an improved version of the old package updater, and anything that’s not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called “System infrastructure“. If you update an application that depends on a package from the “System infrastructure” group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the “System infrastructure” metagroup. Of course, you can descend and pick updates in that group individually like before, if you know what you are doing, but I think most people will just install the metagroup as one lump.

Also, bear in mind that neither app-install or the application data packages are in distros just yet. This stuff isn’t well tested. The packages may steal all your magazines from your bathroom.

Now, I mentioned my ineptitude at designing GUIs. This is where you come in. I would love you add mockups of what you think an application installer or application updater should look like to this page. I’m going to ask Máirín (mizmo on IRC) to help with the design work, so please upload mockups I can share with her and the other design people. Thanks!

HP are recalling more laptop batteries. If you’re affected, can you please email me the output of:

for i in /sys/class/power_supply/*/*; do echo $i; cat $i; done

and I’ll add the required rules to upower. Thanks.

GNOME Color Manager provides a high level interface for applications to use.

One of the things GCM tries to do is making getting profile settings easy. This means associating devices with profiles. This doesn’t necessarily mean connected devices like printers and scanners, as .jpg files from my Nikon D60 have a profile, although the camera has never been connected to the computer. In fact, I’ve got several profiles for my camera, studio lighting, outside full sun and cloudy.

By dragging the .jpg or .tiff file (or even a raw file) onto the “Color Profiles” main window you can create a virtual entry that describes the device that captured the image. All the manufacturer, model and serial number data is obtained from the file metadata and a virtual device is created. This virtual device can be assigned a profile (or profiles) and this color profile can be used in photo viewing programs like eog and shotwell. This makes things magically work, as you can generate and assign the profile in GCM and it works everywhere else.

So what do you need to do as an application developer to get the chosen ICC profile for a file? First, you want to check if the file has any embedded profile (you can get the embedded profile using GTK) as this will always take precedence over a generic profile. It’s unlikely that a jpg photo from a camera will be tagged, although a jpeg file from a scanner (if you’re using a new Simple Scan) might be. Lets assume the file has no embedded profile for now.

If you call the org.gnome.ColorManager.GetProfilesForFile method on the org.gnome.ColorManager session service you’ll get an array of tuples. The first tuple entry is the profile filename, and the second is the profile description which you can add to any UI if you want, or it can be ignored. You just need to pass the method the full path of the file you want to view, and the hint. The hint is a string value used to influence what profiles get chosen, but for now just pass NULL or “”.

Of course, this method should be called async, as GCM will be looking at the file and extracting metadata which might take quite a few milliseconds if it also involves a disk seek. You probably don’t want your UI to block. If you’re already extracting the exif data for the image you’re viewing (like eog) then you can optimize the calls to GCM and only re-request profiles if the ‘Make’,  ‘Model’ or ‘CameraSerialNumber’ changes. It’s usually the case that a huge directory of photos will normally be taken from the same device, and thus need the same profile to be applied. Of course, if you are maintaining a local cache rather than just querying GCM for each image then be sure to watch the Changed() signal on org.gnome.ColorManager and drop any caches if that gets emitted.

There is a lot more information on the new wiki page, along with use cases and a ton of programmer notes. You’ll need to compile git master for the drag-drop virtual device creation and the GetProfilesForFile() method call. All this new stuff is going to be available in GNOME 2.31 too, so hopefully soon we can rock hard and stuff can just work.

Yesterday afternoon my community sponsored ColorMunki arrived. Within hours, I had fixed all the issues using it for display calibration:

Notice the device specific images? If you don’t get images you’ll be directed here and asked to submit images for other users. This just left projector support, which was also pretty easy to add:

So, then I moved onto calibrating printers. Normally people only want to profile the local printer, but I really want to profile the printer I use on a weekly basis: Snapfish. The idea of a print shop is you upload image files and in a few days time you get then back in the mail. Now GCM allows me to generate 7 photos worth of calibration squares and when I receive the photos I can generate the ICC profile so all subsequent photos are color compensated:

All the code is in git master, although the print shop feature is not quite finished yet. Yell if it breaks.

A few months ago, I started working on gnome-color-manager. Now, making a display profile using an external calibration device is as simple as a few clicks and a few minutes of waiting. Quite a few people are keen on me working on printer calibration next, and to properly support spectrophotometers. This means you could generate print profiles with a few clicks of the mouse, just like display profile.

Unfortunately, I don’t have a spectrophotometer, and without hardware it’s pretty hard to add support. The devices are also quite expensive, and not something I can expense with Red Hat (they are kind enough to allow me to work on gnome-color-manager in work time as it is!) Generously, the guys on the gnome-color-manager list have put together a collection. If we can get close to the £320 total, then I can buy a device of my own and add support to gnome-color-manager and work on the upstream CUPS support.

If you’re interested in us achieving this goal, and you’ve got a few quid spare, I would be very grateful. We’ve already got £145 towards the total. Any donations gratefully accepted. If we get close enough, I’ll bite the bullet and convince my wife I need to spend some money on “work stuff”. Thanks.

EDIT: total reached! Many thanks to you all!

Work on gnome-color-manager continues. Display, scanner and camera profiling seems to work very well now, but I would really like to move on to creating profiles for printers. To do this I need to buy some expensive kit, something like a ColorMunki. If anyone has one of these sitting in a draw being unloved, it would be all I need to add support to gnome-color-manager. It’s not something I can expense, as it’s not really part of the day job. Anybody?