GNOME 3.4 for artists? Hell, yes!

GNOME 3.4 for artists? Hell, yes!

Earlier this week GNOME Foundation released the new version of its desktop environment. Some of its components are of a particular interest for artists, photographers and designers.

Those components are the GNOME Control Center applet for configuring Wacom tablets and GNOME Color Manager.

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:

Display mapping for Wacom tablets

The other one is mapping touchstrip buttons to actions:

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.

Calibration with GNOME Color Manager

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.

Was it useful? There's more:

16 Responses. Comments closed for this entry.

  1. Nice. I may give UbuntuStudio 12.04 a spin this weekend.

  2. Very good news !

    I also hope the gnome compositing effect doesn’t affect anymore the painting strokes speed and performance in most programs (2D and 3D) , and it comes with open-raster *.ora preview thumbnails and a minimum of tweaking for changing the theme to work with values ( this was just perfect in Gnome2).

    KDE, XFCE have already easy way to change theme or colors, got *.ora thumbnails, and can work without compositor who eat display perf. So, this Gnome 3.4 for artist is “relative”.  ;-)

    Anyway, the main highlight -and I understood-  in this article are * color management , and wacom GUI. And here again it’s relative to artist needs :
    For the wacom GUI , I must test if I can map a ‘control’ button to the first button stylus and the default 2nd to the 3rd. Or I will be back to xsetwacom command line. It sound a easy user case to just want the color picker to be on the first button, but on the previous Gnome 3.2 GUI, it was impossible.
    For the color management, I must test if it support dual-screen even with the nvidia driver. ( ‘nouveau’ project is nice to support that , but still far to compete about performance for 3D or 2D ). Still I have a calibrator here I must run with only 1 screen calibrated, and the other one ‘adapted’ manually to the first one to not make bleeding my eyes.

    So, I really hopes everything like this will work out of the box and I will have cool surprise.  I’m curious to test.

  3. “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.”

    Hehe why dropping Xorg? What is so different between Xorg client/server communication and wayland application/wayland-compositor communication? Really nothing except some other protocol. Designing a backward compatible protocol for wayland should not be a problem on the technical side. And as we stated on OpenICC, we would like to help with that. Anyway let us know, when you have some technical details to discuss about to bring the whole thing forward.

  4. @Deevad:
    The paint strokes being slow is not gnome compositing’s fault, afaik.
    In my experience it is caused by compiz (used in Ubuntu and Mint) and it doesn’t happen in Fedora or Debian, where mutter is used.
    Apparently there is something with the modifications introduced by Ubuntu developers that breaks things.
    Regarding calibration and profiling of a second display, it’s not possible with twinview, afaik. But that has to be fixed by nvidia.

  5. @Gez : Thanks for the answer :) It’s always hard -as a user- to know what’s wrong. It’s a good help to know who does good job. I will take a look more closer to the benchmark at Phoronix to find a good graphic card running good perf with nouveau. It’s seams like a hardware workaround to fix this.
    For Mutter, good to know. I will test it deeper for sure when it will be released.

  6. @Gez : The ICC Profile in Xorg spec allows for multi monitor ICC profiles per display. It does not depend on any driver. I think inkscape uses this feature.

    @Deevad : for a ICC colour corrected multi monitor desktop connected to a nvidia card look here:

  7. @Deevad: You can try Gnome Shell with mutter in any non-ubuntu distro using Gnome, and it should run well with nVidia binary drivers.
    I’m using Debian Testing and it’s running smoothly with the latest nvidia drivers.

    That’s good to know, but I never found a way make color correction work on multiple displays with nvidia-twinview, at least using Debian and derivatives with Gnome.
    When I had Ubuntu 11.10 and Linux Mint 12 the performance with Compiz was really bad. I thought it was something caused by Gnome, but after switching to Debian and trying Fedora it came clear that compiz and/or some stuff in Ubuntu (and its derivatives) was causing that slow performance, mostly in painting applications.
    I really don’t like KDE, so for me it’s not an option to switch desktops. I wouldn’t go back to Compiz either, since every time I tried was too slow for me (and in the last few versions to the point of being unusable).

  8. *Kai-Uwe. Sorry for mispelling your name.

  9. @Gez np. With what hardware did you run Compiz? Compiz runs here smooth with integrated Nvidia 9300/9400 chips. I do only see delays with that hardware while starting the cube effect. And of course the usual (video) synchronisation glitches under Linux/Xorg.
    Anyway CompICC seems not a option to you with problems under Compiz.

  10. @Kai-Uwe:
    GeForce 9600GT. Seems pretty enough to run compiz, isn’t it?
    It’s running great right now with Gnome 3.2 and mutter. I can hardly see the sync glitches.
    In the same machine running Ubuntu 11.10 with compiz I had to wait for the paint strokes to catch the pointer in mypaint.

  11. @Gez
    Right now I tested openSUSE-11.4 with mypaint fullscreen over a 3200x1200 pixel desktop under Compiz with ICC colour correction shaders on. No matter if small or bigger brushes are used, mypaint stroke and cursor matches pretty well. Your hardware should be quite capable, faster than mine. I have no idea what causes the delays on Ubuntu. But hey, CompICC runs here only under the old 0.8.x API written in C, while Ubuntu 11.10 surely runs the newer C++ Compiz with 0.9.x .

  12. Why the hell Wacom ONLY!? *wall*

  13. Alexandre Prokoudine 06 December 2012 at 6:34 am

    @Sarge That’s explained in the interview.

  14. Thank you for your reply. Hmmm… Waltop support… sounds tasty 0)

  15. Alexandre Prokoudine 08 December 2012 at 3:12 pm

    @Sarge There’s also this interview. Should you choose to read it, here’s an update: Nikolai started contributing to linuxwacom since then.

  16. Thanks! I knew this page existed, but somehow just did not read it carefully. It’s nice to know that digimend is up to it now too. Things may go better with Nicolay’s help.