GNOME 3.4 for artists? Hell, yes!
Earlier this week, GNOME Foundation released the new version of its desktop environment. Some of its components, GNOME Control Center applet for configuring Wacom tablets and GNOME Color Manager, are of a particular interest for artists, photographers and designers.
Wacom configuration tool
The applet for setting up Wacom tablets was added to GNOME in v3.2, but had a very basic feature set initially. Since then the team wrote a new library, libwacom, whose job is to provide a list of device-specific settings for attached graphic tablets and styluses.
Shortly before releasing GNOME 3.4 the team issued and update of libwacom that features support for many more models of Wacom devices including new and shiny Wacom Intuos5.
The configuration applet itself got several essential new features that were promised by the team back when we interviewed Peter Hutterer half a year ago. The first one is device calibration and mapping to external displays that will make users of Cintiq tablets and dualhead setups much happier people:
The other one is mapping touchstrip buttons to actions:
Finally, you can now configure multiple attached tablets and multiple styluses. So if you have, say, an Intuos4 with an Airbrush Pen, you can configure both the airbrush and the regular stylus. Cosimo Cecchi demonstrated that and some of the other new features in this video:
We asked Bastien about further plans, and here is what he replied:
The rough guide is to provide more integration of button mapping with applications, so we could have mappings like “Reduce tip size by 10%” rather than repeating a keyboard shortcut. Then there’s better monitor mapping UI, with cropping support. And tons of bug fixes and polish, obviously.
Sounds exciting, doesn’t it?
GNOME Color Manager
GCM got comparatively less visible changes. There is, of course, new artwork by Lapo and Jakub for each model of supported measurement devices, and a progress bar for calibration if you have a pretty recent version of ArgyllCMS.
Other than that, during this cycle the configuration applet mostly got fixes and low-level changes such as support for MAPPING_device_id metadata field. The latter means that GCM and colord now write some data to newly created ICC profiles that describe specific hardware. When someone else imports such profiles and has identical hardware attached, the newly imported profile will be automagically mapped.
As you very well know, LGW could never resist the urge to ask a developer some questions. But Richard is very, very patient and understanding about that sort of thing :)
What’s the plan for the next development cycle?
For GCM there’ll be some more stuff that Pascal wants, like gamma selection and desired screen brightness during calibration. Now that colord-kde exists, I’m pretty happy with the colord integration points in the desktop.
So now we have to start integrating things lower in to the toolkit, so you can mark a *widget* viewport with a colorspace and it all just works magically.
I’d also like to do color print previews in the gtk printer preview, but that needs a load more work on my secret project before that becomes a reality.
And what about your plans for fullscreen color management (FSCM)?
I want to work with Kristian Høgsberg and Pekka Paalanen on the Wayland color management extension. Actually, I was going to do it this cycle, but I had loads of extra work to do with GNOME 3.4.
What timeframe do you envision for FSCM to be done?
It’s over a year of work, i.e. two GNOME cycles.
You mean full implementation or basics?
Well, actually writing the extension isn’t that hard. I think it’s going to take two cycles for distros to be in a position where they can adopt Wayland, and for my our new protocol extension to get some real world testing with applications like Krita and GIMP.
But you can’t deliver it in small usable bits like you did with GNOME Color Manager and colord?
Well, the big problem is that if I do this as a Wayland extension, it’s not exactly easy to get Wayland running today. And if I patch GTK+, it’ll only work when running as a Wayland client. So I think I can actually code it faster than the distros will adopt Wayland.
Doing it in X is just crazy: X wasn’t designed for this kind of use case, and trying to support both X and Wayland using the same protocol would be some new kind of divine hell.
Back in September you said during the interview you’d be handing around bits of code to implement colord support in 3rd party apps during v3.4 development cycle. What happened to those plans?
It’s done. Code examples are available in colord.
SANE has been “root of all evil” for GNOME Color Manager ever since you added support for scanning devices. How does your newly added colord-sane daemon solve this?
Well, it’s hardly the root of all evil :) It is however responsible for 95% of the crashes in colord in Fedora 16, which is really crap. To work around this, I put the colord-sane code in a separate process and this means if libsane explodes in a ball of fire, it doesn’t take out the colord daemon at the same time. See my blog for more details.
Do you think the community is capable of replacing SANE? Should it?
Well, somebody should replace the core bits. The drivers are probably useful, if a little insane. But the libsane library just doesn’t work in this decade. All sync calls? Non-threadsafe? No, thanks.
How huge would be the work?
Probably a couple of man-months, but I’ve not really scoped it out. If anyone is interested, I would be happy to mentor that kind of project although it’s probably a thankless task. Send me an email if anybody want any more info.
The new version of GNOME featuring all those improvements will be available by default in upcoming Fedora 17 and Ubuntu 12.04.
Patreon subscribers get early access to my posts. If you are feeling generous, you can also make a one-time donation on BuyMeACoffee.
