Carlos Garnacho

Along the last days/weeks, I’ve gave myself the oportunity to tinker with XInput 2.1 in GTK+, now that the core concept of the involved changes seem settled (although corner cases are still being discussed).

Thanks to the previous port to XInput 2.0, handling multitouch events has been fairly easy, by enabling GDK_TOUCH_MASK events on your widget you can receive GDK_TOUCH_PRESS/MOTION/RELEASE events containing a touch ID, which is unique at that time for a touch event stream, so enabling that you can effectively receive events from simultaneous touches.

In addition, one can create GdkTouchClusters (related to a GdkWindow) and add touch IDs to it. from that point on, any update on these touch IDs stops sending individual GDK_TOUCH_MOTION events, instead sending GdkEventMultiTouch events, containing all latest events for the touch IDs in a GdkTouchCluster.

I’m pretty happy with the resulting API, althought there are some internal details left to improve, my main gripe currently is that implicit grabs in CSW still happen per device, this means no multi-widget multitouch yet within an app (also posing interesting problems with keyboard events redirection and explicit grabs). Another big item is looking into integrating this with gestures, as direct manipulation and gesturing need to go hand in hand, so that branch could be discontinued in favor of this one.

As I’m pretty lazy, and the results would be strikingly similar to what I previously posted, I won’t post any video, so you’ll have to settle for a screenshot:

This is sitting now in the xi21 branch. If you just compile this you won’t see much working though, the demo only reacts to touch events, which are only sent if XInput 2.1 is there, which requires compiling certain Xorg modules branches, and having a multitouch device at hand.

Fixing the default GNOME3 theme

Now that most of GTK+ widgets are using GtkStyleContext, I finally got onto improving the default gnome3 theme/engine, I finally chose to rip off the tiny clearlooks engine bits I needed to demonstrate how minimal engines can complement and extend the current CSS theming features. So things are getting closer to the mockups:

There are some things that still need to be improved, column headers and expanders most namely, but things should be mostly there pretty quickly. Even though, hands and eyes are most welcome on both the CSS file and the engine.

A gestures interpreter for GTK+
Despite what some might think, my day to day work carries me quite far from theming land, during the last week I got the oportunity to start development on a gestures interpreter for GTK+, a pretty interesting (read: wacky ) piece of dynamic programming, that seems to work pretty well for its builtin gestures (Video here, at the moment it handles swiping in the 4 directions, plus circular swipe in both directions)

This code lives at the moment in a GTK+ branch, including a testcase. The gestures interpreter at the moment handles individual pointer movements separatedly, although it may be improved over time to handle multiple input pointers, as the interpreter itself is private and widgets just get an enum for the gesture type.

As the stock gestures could be stored in terms of coordinates or vectors, future plans include having these stored in a mmap()-able format, plus having an editor to create new gestures.

For those building gnome3 frequently from git or paying attention to gtk-devel, this might be old news, but still worth mentioning… The gtk-style-context branch has landed in GTK+ master, which will quickly unveil a powerful theming system, powered by CSS files.

Although some apps (mostly these implementing widgets themselves) might undergo some work to adapt to this, there are API docs and migration documents (mostly courtesy of Matthias, who’s done an excellent work) that should ease the task.

Besides the GTK+ work, there is also both a gnome3 theme and engine using the new stuff. Things are still ongoing here, as many things can be leveraged into CSS, which would leave the engine very little things to do. Andreas started looking at some point into the branch, so he might have some things ready in that field :).

But not only that! Carlos Garcia Campos (KaL) has been doing good progress on webkit-gtk so no backing widgets creation is needed, and Paolo Borelli has ported GtkSourceView as well, awesome!

On this weekend I’ve returned from the GTK+ Hackfest in A Coruña. All in all, it’s been a really intensive event, so much that apparently many of us have been to exhausted to blog :P, there have been lots of ideas and interesting topics to discuss about, and lots of goodness have landed in git (GPeriodic, GtkGrid, input/output windows removal, GdkRGBA, …). Most importantly, a roadmap is taking shape!

Personally, I’ve been working during the past week on the gtk-style-context branch, adding some missing features and improving how things render in general. In that branch, you could see something somewhat boring, as we are accustomed to:

But then with this CSS in ~/.gtk-2.0.css:

.background {
    background-color: rgba (0.2, 0.2, 0.2, 0.9);
}

.button {
    border-radius: 5;
    border-width: 1;
    background-image: -gtk-gradient (linear, left top, left bottom,
                                     from (shade (@bg_color, 1.3)),
                                     color-stop (0.55, shade (@bg_color, 1.1)),
                                     color-stop (0.55, shade (@bg_color, 0.9)),
                                     to (@bg_color));
}

GtkButton:hover {
    background-image: -gtk-gradient (linear, left top, left bottom,
                                     from (shade (@selected_bg_color, 1.3)),
                                     color-stop (0.5, shade (@selected_bg_color, 1.1)),
                                     color-stop (0.5, shade (@selected_bg_color, 0.7)),
                                     to (@selected_bg_color));
    transition: 200ms ease-in-out;
}

GtkBox > GtkBox > GtkButton {
    background-image: -gtk-gradient (linear, left top, left bottom,
                                     from (shade (rgba (0.2, 0.2, 0.2, 0.8), 1.3)),
                                     color-stop (0.55, rgba (0.4, 0.2, 0.2, 0.8)),
                                     color-stop (0.55, rgba (0.6, 0.2, 0.2, 0.8)),
                                     to (rgba (0.3, 0.3, 0.3, 0.8)));
}

GtkScrolledWindow {
    background-color: rgba (0.3, 0.3, 0.3, 0.7);
}

.trough,
.slider {
    border-radius: 3;
    border-width: 1;
}

GtkBox > GtkLabel {
    font: Sans 15;
    foreground-color: #f00;
}

Turns into something uglier yet exotic (note:provided the GtkWindow has an RGBA visual, I’ll leave that as an exercise for the reader):

Lately, I’ve been intermitently working on the gtk-style-context branch, which is meant to supersede GtkStyle and get rid of all its limitations in creating contemporary UIs, to name a few:

• Cairo as a first class citizen: This means elements may be rendered on any surface, not only on X resources.
• No more widget peeping: There is now a GtkWidgetPath abstraction, which fully defines the widget in a styling point of view.
• Widget is no longer a plain area: Widgets may define named regions, which can be styled independently.
• Animation support: Theming engines no longer have to hack their way to animate some UI element, there is built in support for animations on state changes.
• No more detail string: GtkStyleContext may contain several classes, which can be checked by the theming engine.

As a consequence, the GtkRC parser has been replaced as well by a CSS-like parser, the property names aren’t currently fully following the CSS spec (Selectors do), and there are some semantics that don’t apply, but OTOH there is support for symbolic colors. The format is enough for people into web development to get the gist of it:


@named-color: #01a4f9;

/* Animate checkbutton transitions */
GtkCheckButton:active {
  transition: 200ms ease-in-out;
}


If you compile the gtk-style-context branch and put this into ~/.gtk-2.0.css, you should see something like this:
(Disclaimer: this is the default engine, I know it’s ugly, let’s leave art for artists)

At the moment, widgets have been roughly ported to this new code indirectly through making GtkStyle rely on GtkStyleContext, so they could be a lot more talkative about the elements they render and contain. If you’re a theme engine developer try out the GtkThemingEngine API, this is what theming engines must implement and use in order to render UI elements, constructive feedback is most welcome.

There are many things going on in this field, from the recent merge of the xi2 branch into GTK+ master (yay!) to the ongoing effort in Xorg to support multitouch devices.

I’ve worked myself in a proposal to the evdev driver so it deals with multitouch devices as a set of XI2 devices (in GTK+ world, this means each finger would be represented by a GdkDevice), only one finger is able to send core events, while the others only get to send XI2 events, this seems pretty much in line with Peter’s thoughts on multitouch support

I also have a few patches in the xi2-playground branch that understand these semantics and basically make multitouch work out of the box.

So, if you have a multitouch device that’s understood by the linux kernel, these are the ingredients:

• Xorg 7.5 (Recent Fedora and Ubuntu have this)
• My evdev driver branch
• For N-Trig devices:
  • hid-ntrig driver from Linus’ tree (seemingly included in Ubuntu Lucid)
  • This xorg.conf.d file (a similar file might be needed on different hardware)
• GTK+ from the xi2-playground branch

Voilá! xinput list should tell something like:


⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ N-Trig MultiTouch id=12 [slave pointer (2)]
⎜ ...
⎣ Virtual core keyboard id=3 [master keyboard (2)]
...
∼ N-Trig MultiTouch touchpoint 0 id=13 [floating slave]
∼ N-Trig MultiTouch touchpoint 1 id=14 [floating slave]
∼ N-Trig MultiTouch touchpoint 2 id=15 [floating slave]
∼ N-Trig MultiTouch touchpoint 3 id=16 [floating slave]


And the GTK+ tests in tests/multidevice/ should just work, providing at the same time a single-touch device feeling to applications unaware of XI2 or multiple devices.

Guadec
If you find this subject interesting, don’t miss my guadec talk! where I’ll be talking about multitouch in GTK+ and what applications can do to support it.

So, for the first time ever (to my knowledge), the full multi-touch stack working on Linux:

This video features:

• Linux 2.6.31 with the N-Trig driver (Plus some modifications of mine to have multitouch enabled with my touchscreen firmware)
• Xorg 7.5
• xf86-input-evdev-multitouch (By the ENAC people, plus some patch of mine to cope with devices that don’t provide tracking IDs for each tracking point)
• GTK+ from the xi2 branch
• Eye of GNOME (plus a small patch to handle multidevice events)
• Valen, the turtle

In my opinion, this is a quite important milestone, which reflects much work done lately in this camp, and from now on things can only get better!

And of course,

Ok, next blog post was supposed to be about multitouch and such as I promised, but that will have to wait a bit, let’s see why:

Today’s history is about N-trig, HP, and lots of idiotic behavior around. In order to have a better insight about multitouch, and seeing that the Thinkpad was aging, I decided to get a HP Touchsmart TX2 tablet. All in all, a nice computer, quite better than the old one, and there has been work lately on getting the N-Trig multitouch+stylus device working on linux, all fine! but wait…

WTF #1 (N-Trig)
After I started experimenting with the Linux multitouch input interface, I promptly realized I wasn’t getting multitouch events at all, why? turns out the N-Trig device had a firmware meant for Vista, and that I should install Windows 7 drivers in order to get the newer firmware that would allow multitouch events.

Yes, right, drivers and firmware are bundled in a single installer, so when you install such thing you must plug your laptop, remove it from the expansion base and cross your fingers (away from the screen of course), could something go wrong? of course, and it did for me, leaving me with a “N-Trig hardware not detected” message whenever I try to reinstall or uninstall the driver, so no reflashing will happen, leaving the touchscreen completely unusable under any OS.

In conclusion: Hardware manufacturers should stay away from hardware unless they hold a soldering iron, seriously, leave software to others.

WTF #2 (HP)
After this, the only feeling of relief I had was due to the laptop being under warranty, easy, ain’t it? It isn’t. After several long calls to their customer service, they still insist that I must purchase a recovery kit DVD set (I wiped the recovery partition out, no DVDs were shipped with the laptop) for 40€, so they can check remotely themselves (eek) that it’s actually a hardware issue. There are several problems with this:

• According to Spanish law, enjoying any product warranty must imply no cost at all to the customer. I told them so and they dared me to sue them, I’m already looking into doing that.
• They stated that they can only support a computer warranty with the pre-installed OS. However, in the booklet shipped with the laptop, it is mentioned that they don’t guarantee at all any shipped software. They’re just supposed to offer limited technical support the first 90 days (which already expired).

I’m currently trying to bypass phone customer service with the e-mail one, they at least seem more indifferent to me having other OSs, let’s see if I succeed.

In conclusion: looks like HP customer service’s only target is to cause grief and frustration, you don’t only deserve being sued, you deserve to die young, in pain and alone.

</rant>

XInput2 GTK+
Sadly the only thing preventing me from sending a preliminar patch is polishing XInput 1 support, it was mostly readapted to GdkDeviceManager and the event handling refactor, but there are some glitches here and there. All this is now stalled by having the tablet functionality broken, if anyone wants to pick this up, please tell me (garnacho at #gtk+, etc) and I’ll try to help you through the code.

Likewise, non-X11 backends are completely untamed land, these need readapting to GdkDeviceManager and _gdk_windowing_* API changes, contributions there are more than welcome.

Seeing that Martyn has updated his blog with some sweet tracker info, I figured I could do the same

The main feature I’ve been last working on (together with Martyn) is libtracker-miner, Which will ease the creation of data miners for tracker-store (that is, objects that extract useful info from applications and such and transform it into SPARQL, which is pushed into tracker-store).

The idea behind this is that one can develop both independent miners and plugins for the most popular applications which translate data to something Tracker can understand by implementing the TrackerMiner object.

This object also implements control logic, so the control of all available miners can be reduced to a single point, there is also a reworked tracker-status-icon which does precisely this, this is how it currently looks like:

There is also a TrackerMinerFS base class, which eases directory crawling, monitoring and other filesystem features. This is the base object for both applications and files miners.

XInput2 + GTK+
There’s much progress going on here, I empirically suck at blogging, but I promise I’ll make an update about this soon

So, today is officially the last day for the hackfest, it’s been a quite exciting week, with lots of discussions, ideas flowing around and crazy experiments, which had lead us to an agreement on how should a new theming infrastructure be.

People here have been working really hard to get different parts of the lower level infrastructure right, such as CSS theming, the GStylable interface, hit detection for non-rectangular shapes, etc… I’ve been mostly focusing on the replacement for GtkStyle, this is what has been achieved so far in that field:

1. Current API limitations: GtkStyleContext would be able to store any kind of data, it’s kind of a hashtable with save/restore habilities, being able to store much more information that could be relevant to engines (goodbye detail string! goodbye widget peeping!), All drawing would be done on top of cairo, one important detail is that the engine wouldn’t get even get the widget pointer (quite necessary for third-party projects using GTK+ theming)
2. Animations: These are focused to state changes and are mostly implicit if they affect the whole widget. The style context has to be told if they affect part of the widget though (a checkbox in a cellrenderer, for example). There can also be several animations for different state transitions running at the same time:

Parallel prelight and checkbox animations running, slowed down for appreciation. Glitches will be fixed by correct properties inheritance
3. Containers are able to pass placing information to children’s context: Think comboboxes, spinbuttons, notebook tabs, … Now painted elements can get a clue about how do they connect visually with other nearby/related elements. Of course engine implementations will be able to just ignore this information.

Rounded pathbar

Nevermind the ugly rendered elements, that’s up to artists :). The code is in my github repo, in case anybody wants to give it a try.