In GNOME 3.0, we’re defaulting to suspending the computer when the user shuts the lid, and not providing any preferences combobox to change this. This is what the UI designers for GNOME 3.0 want, and is probably a step in the right direction. We really can’t keep working around bugs in the kernel with extra UI controls.
This will upset people who are docked or using a laptop for a presentation with a projector. Worry not! If you have more than one active screen connected to the machine, then we’re going to just disable the internal screen and not suspend until the second screen is removed.
This will upset some macbook owners if they connect a projector and then shut the lid. Some macbook laptops overheat when the lid is closed and not suspended, leaving the owner with a hot white glooopy mess when they finish their presentation. This is something we can do something about, but I need the help of the community to work out what makes and models need to be blacklisted.
If you own a laptop that gets very hot and starts to smell like hot plastic if you shut the lid without suspending, please send me the output of dmidecode and I’ll add the entry into upower. Thanks.
For three days last week I attended a conference on application installing in Germany, hosted by Vincent Untz and the other guys from Novell. There were experts sent from Fedora, Ubuntu, Debian, Suse, and Mageia. From Fedora both I and Florian Festi attended.
The idea of the conference was to talk about defining some APIs we can share, to discuss interchange formats, and talking to the UI designers to make installing and removing software on Linux suck less.
Overview:
Lots of progress, people were willing to help solve a common problem in a unified way.
The right people were at the meeting and we came up with a really good technical plan with action items.
Ubuntu Software Center really kicks ass, although we really need them to drop the CLA. USC will be ported to use PackageKit in the next couple of weeks.
Packages and packaging are not that interesting to the end user.
We will integrate with online social services to provide features like ratings and comments using OCS. OCS needs a couple of things added to the API, which will happen in the next few weeks
We will produce appdata.xml metadata per-repository, rather than one super-package.
I need to talk to the fedora-infrastructure guys – it might make sense to not refresh the metadata every day for the rawhide compose.
We will use a xapian index to query the desktop metadata, rebuilding as repos are added / removed. This supports fast stemming and other advanced features.
Will add several new optional fields to desktop file specification upstream for the proper solution, more details to come soon. This will allows us to search for photoshop and return gimp in the search results.
Non .desktop files as applications do make sense, e.g. firefox plugins as .xpi or Chromium style web links. This makes sense to push to OCS, rather than in the distro metadata.
What this means for Fedora:
We add a tiny script (to be written this week) to generate the xml file and the icon tarball for the distro at compose time (similar to my earlier app-install work)
We ship the extra optional metadata in the fedora mirrors (+~9Mb)
We download this in PackageKit if a repo is enabled or refreshed
We’ve put a few detailed documents with architecture plan on the wiki and Vincent has also uploaded all the notes from the meeting to the same location.
For more information still, there was a presentation we gave at the end of the conference. It’s nearly an hour and gets pretty technical, so get coffee before if you click the video.
Thanks again to Red Hat for sponsoring my travel and hotel expenses.
In the last couple of months, I’ve been talking quite a bit with Tim Waugh about color management of printers, and how to achieve working CM with CUPS. At the moment, gnome-color-manager locates CUPS devices and allows the user to calibrate them and assign profiles, but CUPS doesn’t actually use the assigned profiles for printing. Oops.
Needless to say, the combination of CUPS, ghostscript and other complicated little-known parts of the printing stack make this look almost impossible. OSX uses CUPS and CM works really well on printers using Apple products — and so it must be possible. We need to make it work on Linux too before Linux can become a serious option for artists and media professionals.
OSX uses a system-wide framework called ColorSync that does all the device<->profile mapping, and allows the user to change the ICC color profile for each device, and also allows the user to choose internal profiles listed in the printer definition file. ColorSync works really well, and is an integral piece of the OSX operating system.
GCM is a session process that provides session programs access to the per-user color management settings. Because GCM is running in the session it can integrate deeply into the GNOME desktop environment and is not particularly security sensitive. But, because the framework is per-session, system frameworks like CUPS cannot access the data, and we also have to rely on cludges like naming the display ICC file to be the same as the device ID and putting it in a well know location to be able to have a color corrected GDM screen. Urgh.
So, we need a trivial device<->profile daemon that works like a subset of ColorSync that the session GCM instances can use for defaults and also set profiles system wide for projects like CUPS. Over the Christmas holidays I wrote a small dameon called colord that provides a way for applications (or other daemons) to create, destroy and assign devices and profiles.
Devices
colord doesn’t do any file parsing or anything terribly unsafe, it’s just a simple system activated system DBus PolicyKit enabled daemon that has a simple database of devices that can reference specific profiles. Profiles are optionally assigned ICC profiles, and also have qualifiers that can be used to match them. For instance, a qualifier could be Epson.RGB.300dpi, which would match from the qualifier search of “Epson*”.
One thing to note: colord isn’t anything related to systemd. The name was chosen because colordaemon was too long to type and ColorManager and ColorKit names were already taken. It’s also intentionally techy, as users are not going to have to interact with colord whatsoever.
At the moment there is a test GTK application for developers and color geeks shipped in the colord package, but long term GCM is just going to use colord and all the configuration and settings will be done in the session by GCM itself.
Profiles
Tim is working on the CUPS parts as I speak, and hopefully we can have something working in a few days. Exciting times.
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:
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!
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.
