From my Own True Love (Lost at Sea)

Third day of the GTK hackfest. They have taken the bridge and the second hall. We have barred the gates but cannot hold them for long. The ground shakes, drums… drums in the deep. We cannot get out. A shadow lurks in the dark. We can not get out… they are coming.

today, the topics discussed were two:

  • ClutterBenjamin, Matthias, and I discussed how to integrate Clutter with GTK in the future. the plan that is shaping up is to hollow out GtkWidget and make it the minimal semantic unit of the structure of an application; a button, a combo box, a text entry, etc. each widget would then be composed of internal elements — the background and the text for a button; the icons, the progress bar, and the text, for an entry, and so on, and so forth. each element maps the CSS box model (as far as it makes sense), and it’s backed by a ClutterActor. layout management of each element, and rendering, is deferred to Clutter. so, each GtkWidget has-a ClutterActor, that you can also access to use Clutter directly. implementing a GtkWidget would then be simplified to actually building the structure that has to be rendered, drawing with Cairo on provided surfaces if you have custom content instead of primitives like texture data or text, thus leaving the rest to the scene graph underneath. while this is not a radical change in how GTK+ works, we’re definitely considering bumping to the 4.0 API version — this time it wouldn’t be such a quantum leap like it has been for the 2.x to 3.x transition. all this work depends on the Clutter 2.0 effort, which will take the bulk of the next cycle for me. hopefully, with a little help, we’ll be able to do a GTK+ 4.0 in 12 months.
  • design — after lunch, we all sat down with the GNOME designers, and talked about the direction for the toolkit, especially with regards to enabling touch on widgets, and adding more widgets that are touch-oriented to be used when designing applications for touchscreen environments. we also discussed a lot about themeing, and how app developers should use or depend on themes like they do on ABI. then we went through the design whiteboards section of the wiki to see what tasks involve the toolkit — like printing, notification, selection, and content selection.

all in all, it was a very productive day; we’re churning through the agenda points at a fairly good pace, and hopefully we’ll soon be able to work on all the areas that have been identified, in order to make GNOME rock.

Youth and Beauty Brigade

first day of the GTK+ Hackfest.

while we waited for various participants to arrive, discussions started on a couple of topics:

  • accessibility — Benjamin reported on the various discussions and deliberations that happened during the latest Accessibility Hackfest; what we want to achieve is a state in which the accessibility team has fewer headaches working around issues in the toolkit, and can instead work on the toolkit itself. there is also a question of what kind of API to expose to application developers, not just for people writing AT apps, but also for people writing UI testing suites.
  • multi-touch — Chase, Benjamin, Ryan, and occasionally myself, caught up a bit on the overall issues of what kind of API to expose from GTK+ to applications, and what kind of approaches we should be using internally. the bulk of the discussion will resume either this evening, where alcohol will be involved in making them long and very much detailed; or tomorrow, where hangover will keep them focused and short.

plus, people were really interested in the correctness of the regular expression on my tee, which was initially amusing, up until the point a whiteboard and a state machine were involved. occupational hazards, I guess.

I also want to point out that at no point knives, or other weaponry, was involved in the various discussions.

I’d like to thank Red Hat (and the Red Hat office in Brno) for offering the conference room for the hackfest.