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:
- Clutter — Benjamin, 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.
today I spent the morning at the Developer Conference: Matthias had an interesting talk on the changes that happened in GTK+ 3.x over the past year, as well as his experience in implementing the new
GtkColorChooser after the design proposals.
then it was multi-touch time. after a recap of what happens on different platforms and different toolkits, we discussed and reviewed the API proposed and implemented by Carlos Garnacho; after a quick break for a late lunch at 4pm, the discussion resumed — it’s actually still going on to this very moment: Chase, Benjamin, and Matthias are now discussing about event controllers and gesture recognisers — and how to design event handling in the Brave New World® of touch events and gestures.
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.
after a rather interesting, albeit not really eventful, journey that spanned cars, buses, a train, and a plane, I’m finally in the lovely Brno — with 2 degrees Celsius and a lot of snow — for the 2012 GTK+ hackfest.
unlike the previous two hackfests, and against my usual inability to write interesting stuff, I’ll try and live-blog the event as much as I can.
as you can see on the wiki page, the agenda is pretty dense, and it’s going to be an intense 6 days hackathon, filled with discussions as much as coding. my part? talking about rainbows and unicorns, obviously.
a lot happened in the months between the Desktop Summit in Berlin, where we first sat down and talked about what Clutter does, and what GTK needs; there has been various progress in the Clutter API towards a sane base for a 2.0 release. if you try and compile an existing application using Clutter with the 1.9 developers snapshots, you’ll notice the depth and breadth of deprecations and API additions. a lot more needs to change — and some of this work on getting from here to there is detailed on the Clutter wiki, under the not at all threatening name of Clutter Apocalypses. I’ll try and write other blog posts about how I envision those changes, and why I think they are necessary for a 2.0 API version.