The GTK+ hackfest continued on Sunday and Monday. These were days full of good discussion and hacking, but we still managed to catch some of the nice spring weather outside.
Since we are meeting at the OLPC office in Cambridge, there’s plenty of lunch choices around in walking distance.
So, what have we achieved so far ? Lets start with a few old projects.
The file chooser sidebar is now a public widget, and nautilus will use it in 3.10. This will address long-standing complaints that the file chooser dialog looks and feels subtly different from the file manager. Federico has been working on this for quite a while.
Another old project that we’re finally wrapping up this cycle is composite containers. In a nutshell, this means (a) less lines of code in complex GTK+ widgets like the file chooser and (b) you get to create such complex widgets in glade in a structured way.
Tristan and Juan worked on this for several years. Tristan wrote about it here. This branch was actually merged a few days before the hackfest (good thing too, since last-minute scheduling complication prevented Tristan from attending).
Alex has just merged his baseline alignment branch – this lets us align widgets like spin buttons, buttons, labels so that their text is at the same level, visually. The effect of this will be subtle in most places, partially because we have trained ourselves to avoid layouts where (lack of) baseline alignment would be very noticeable. I’m listing this among the old projects even though Alex’ work on this doesn’t have a long history, since it was part of the original height-for-width geometry management gsoc project long ago.
The stated goal for the hackfest is new widgets to support modern applications like gnome-documents or gnome-music. As the patterns for these applications were developing over the past year or so, we’ve used libgd as a staging area where these new widgets could be shared between applications, but they really belong in the GTK+.
So, what has been achieved ?
GtkHeaderBar was already integrated a few weeks ago as part of the client-side decoration support, and I’ve written about it here.
GtkStack and the associated GtkStackSwitcher have just appeared in GTK+ master. Taken together, these two can replace GtkNotebook in many uses (though it is not a 1-1 feature-complete replacement. E.g GtkStack does not support tab drag-and-drop). A nice new feature of the stack widgets is that the transitions between pages can be animated in various ways. This kind of animation is reasonably easy to do in GTK+ now, with the new frame clock framework that we have since 3.8.
You can see GtkStack and the switcher in the video above. I’ve slowed down the transition there to make it very obvious, it is normally much quicker.
Another new widget that makes use of animation is GtkRevealer, which can show a child widget in an animated fashion. This is commonly used to implement in-app notifications, or for sidebars that should not appear abruptly, but smoothly. Compared to GdRevealer, the GTK+ version has been generalized a bit: the child can slide in from any direction or it can fade in. We’ve also added rtl flipping support.
The ‘is a multiple of 3’ popup in the video above is an example of the revealer in action.
What’s still cooking ?
The last big new widget on our wishlist is EggListBox. This one is not quite ready to be merged as-is, but after our discussion, we now have a list of what is missing:
We agreed that we need a row container widget – being able to add arbitrary children to the listbox is very nice, but without an intermediate container, handling selection state, focus drawing and accessibility is a bit problematic. Alex is looking into adding this to EggListBox (and EggFlowBox).
The other thing we need for scalability is a way to hook up a data model and only instantiate rows as they are needed, instead of populating the entire list or grid at once. Benjamin has prototyped this long ago, in the wip/list branch. While we eventually need this, many of the current button-box-like uses of EggListBox are working just fine without it.
Apart from new widgets, we’ve looked at all the GtkSettings and have plans for how to deal with many of them in better ways. Some will require more work (like getting rid of modules), others will be easy (like can-change-accels – just stop doing it).
Of course, plenty of other cool stuff has been hacked on on-the-side, and may has already landed or may still find its way into GLib or GTK+ before too long:
Cosimo and I have spent some time on client-side decoration, and fixed some issues. There are no more black flashes when complex widgets are mapped, opacity works again, and the theming has been simplified.
Alex has a branch that simplifies the gdk drawing scrolling model. Initial tests with this are very encouraging, so it will likely find its way into 3.10 after the few remaining problems have been fixed.
Ryan has committed a nice speedup to GObject instantiation, and while at it, made GLib behave nicer when running under valgrind – it is no longer necessary to set G_SLICE=always-malloc manually.
Once again, thanks to the OLPC for hosting us in their offices, and thanks to the GNOME foundation for travel assistance.
8 thoughts on “GTK+ hackfest, days 3 and 4”
Nice work! I have one question with regards the new file chooser implementation: is the “search” feature going to be removed? Because I can’t seem to see it in the screen-shot and I find it REALLY useful.
Search is not available in the sidebar right now, unfortunately. My plan is to make it work like in Nautilus, accessed through a toolbar button.
The general idea is to make the file chooser dialog look and act as similar to Nautilus as possible.
Oh I see, thanks for your answer, I hope it gets in time for 3.10 🙂
I hope so! My next task is to make GtkPathBar public, and merging any differences from NautilusPathBar. This is the first step in making the whole top bar of the file chooser consistent with Nautilus.
It looks like some good progress. The work that has gone on in GTK over the past few years has been phenomenal- it has really matured as a toolkit. I’m looking forward to the new possibilities we have for making modern interfaces in 3.10.
What will GtkSettings use as a backend in Wayland? Simply gsettings? Or will there be any Wayland-compatible alternative of XSettings so that other DEs could make use of it (i.e. for storing the theme name)?
So much work and topics in so few days, wow! These hackfests are really pushing gtk+ forwards! Nice to see so much activity. Thanks to everybody for their hard word!
When unifying file choser please keep in mind click policy!
Really waiting for this!
Comments are closed.