GNOME_ME_HARDER

this week i’m at uds with vuntz and andreas.

there was obviously a big announcement yesterday. enough people are commenting on that already, and i don’t have anything that i really want to add to that conversation.

on a more positive note, i want to mention something that was agreed during one of the desktop sessions yesterday morning.

based on a promise made by jono bacon that gnome-shell would be an absolutely first class citizen in ubuntu (just not included on the CD) and in response to the lessons learnt from the failure of “stracciatella gnome”, we proposed the creation of an environment variable. if set, it disables the effects of any ubuntu vendor patch to upstream components when those effects are related to gnome-shell vs. unity integration.

what this means is that you will be able to login to a gnome-shell ubuntu experience that works properly, without all of the applications assuming that they are trying to interact with unity.

i like the name GNOME_ME_HARDER, but i guess they’ll probably want to do something a little more boring.

the specific parameters of the promise that was made are as follows:

1. for new vendor patches, this “works with shell” functionality will be required in order for the patch to be considered functionally complete for inclusion.

2. for existing vendor patches, missing GNOME_ME_HARDER functionality will be considered as a bug. this means that issue will receive the same treatment as other bugs — it will be fixed if there is time, patches welcome, etc.

gtk hackfest, day 2

codethink sent me to the gtk+ hackfest this week, hosted in the igalia offices. some really nice things are happening there so far.

first of all, i landed GApplication on glib master (and in gtk too). sorry for any breakage that may have caused. actions support should be coming soon…

second, after some discussion with emmanuele, i sent out to write a paint clock that could be shared by both gtk and clutter. i stayed up until 4am last night dumping my brain into vim and the result of that work is in glib (gio) in the form of GPeriodic. there is also a branch in gtk (wip/paint-clock) that uses GPeriodic to schedule repainting of windows and (for example and proof of concept) to animate GtkSpinner. presently cody is working on a somewhat less-trivial case: making GtkExpander animate smoothly. emmanuele is currently attempting to rebase clutter’s master clock on top of it, so the end result is that clutter and gtk should be on the same clock by the end of the week.

there is not currently any support for merging of input events. that’s mostly due to the fact that it’s a really hard problem and we probably won’t get a chance to deal with it at all before 3.0.

the other thing that we’re working on this week is reducing the GdkWindow abuse that occurs in gtk. samsung sent a few hackers to the hackfest, and one of them (boram) is trying to replace the 2+n input/output GdkWindows in GtkEntry with input-only windows. we believe that this is a reasonable intermediate step to improve use of the new gtk_widget_draw() api without having to think about the input issues (again, because they are quite hard).

i’m personally about to set out on a GtkViewport reimplementation that, first, behaves very naively by always redrawing everything and later caches the content of the scrolled area in an offscreen window (including some of the non-visible areas as a sort of pre-fetching).

there is some talk that gtk4 may be coming in the nearer future than any of us anticipated……