Roadmaps…

Aaron Toponce over at the Utah Open Source Planet, wonders when Gnome 3.0 will show up. I’m guessing there was some poor choice of wording, because much of the entry unfortunately reads something like “project progress is directly proportional to how much the version number increases” and noting how Gnome is still using 2.x.y version numbering. As noted below, I don’t think this was his real gripe; also I think Stuart already did a good job of addressing that point (and others). But I thought there was a good point Aaron brought up and a few other things worth addressing:


Now, can someone explain to me where GNOME is headed? What is it’s direction?

I believe this was probably Aaron’s real pet-peeve. And I think roadmaps are a real shortcoming of ours. Due to Luis’ frequent reminders, maintainers are beginning to announce some plans when they announce creating a new stable branch — but none of that information is showing up at the wiki RoadMap (which only has one item currently listed for 2.16!!!), let alone in any more public places or news articles. Even the announcements on d-d-l at branching time tend to only include a few details; lots of plans just aren’t announced until the work is nearly or completely done (if even then). While this may partially be a result of having time-based releases instead of feature-based ones (since it allows us to be lazier about collecting feature plans on a large scale), it still seems like something that we could improve. Perhaps a GnomeGoal to at least get the already announced plans into the wiki would be a good start?


And what do you mean by “it will be our first opportunity to make a clean break from the 2.x series”?

Libraries in the Gnome Platform and Gnome Bindings maintain API and ABI backward compatibility, so that applications do not need to be manually modified or recompiled to work with newer versions of these libraries. (The API/ABI guarantee is a little less strong for the bindings; you can read more at the links above for details) So, the text you quoted was related to the commonly assumed position that the API/ABI backward compatibility promise is tied to the version numbering, though some point out that perhaps the two should be independent.


In other words, you (meaning the developers) don’t like the 2.x series, yet nothing is being done about it, or you’re going to fork 3.0 with the current 2.x releases? Interesting. I do find if funny, however, that you have a project writeup with a bunch of developers whining about what they want to see…

I tried to avoid some of the more colorful sections of your post, but it seems like this is one where you’ve made assertions that others might not recognize as such. Daring to speak for others for a moment despite taking you to task for doing so: We love the 2.x series. I don’t know what makes you think otherwise. And I don’t see how the Topaz wiki page constitutes whining (I do agree that it looks like a random hodge-podge of wacky pie-in-the-sky ideas; but I thought that was its intent 😉 ). To be honest, my personal opinion about 3.0 is: Who cares? I don’t see anything holding us back in 2.x.y. We can and do implement whatever features and infrastructure we’re interested in. And, ultimately, just like others have pointed out, it’s just a version number. 🙂

Google Summer of Code

Got a cool comment from “John” in one of my previous entries asking if I could get Gnome signed up as a 2006 Google summer of code organization. That’s probably work better done (or delegated by) the foundation board of directors (and I’ll note that Vincent already verified that Gnome will be one of the organizations), but I’d like to draw your attention to the Ideas for projects that are going up on the wiki. So, maintainers, hurry on over there and add your input. 🙂 Yeah, I know, I need to get my own act together and come up with ideas for some of the projects I’m involved in too. I’ll do that…

Now, unlike last year, I might actually be eligible to participate as a student. If so, I might as well as I’ll already obviously be spending time on my addiction, er, I mean hobby. 😉 Makes me wonder though…I didn’t see anything in their student FAQ or mentor FAQ about participating as both a student on a project and as a mentor to others on other project(s). Would that be disallowed? Hmmm….

Metacity Goals

Inspired by Vincent’s
awesome Gnome Goals
project, I decided to do a much smaller Metacity Goals project.

These are simple coding tasks for those wanting to get started in
Gnome. The first step is to build a CVS version of Metacity — this
is much easier than you might expect because you do not need to build
all of Gnome (or even any other modules) and you don’t have to actually install it. Just follow the few steps in the “Minimal
Building/Testing Environment” section of Metacity’s HACKING
file to do this.

Second, pick out a Metacity bug. There are a half dozen or so easy
ones that I’ve put on the gnome-love
report
(which can help you get involved in many other modules too). Of course, the ambitous can just look through bugzilla
for bugs, but I thought I’d point out some ones that I thought would
be easy (and which haven’t already been jumped on by someone else):

  • Bug
    335076
    — Maximizing and unmaximizing windows doesn’t raise
    them

    Björn left good directions on how to reproduce, I listed the
    relevant functions that would need to be fixed and other
    example functions showing how similar stuff has been fixed
    elsewhere. There are two closely related issues in this bug
    and both should be easy to change, though we’ll need some
    usability guidance one whether we want to change the second.

  • Bug
    335351
    — Support sibling from restacking ConfigureRequests

    Turns out there was a FIXME in the code that just never got
    implemented before because of no requests, but now we have one
    (and I’d like it for a few other things too). I pointed out
    what part of the code needs to be fixed and another section
    that has code very similar to what’s needed in the fix.

  • Bug
    338361
    — Focus with maximize/unmaximize keyboard commands
    and sloppy/mouse focus

    Good steps to duplicate and like the above two bugs I point out
    the functions you’d need to look at.

  • Bug
    334899
    — Right clicking on icon for minimized window and
    selecting close can result in a “are you sure you want to
    exit?” dialog that isn’t shown.

    I’m prety sure this is a one-liner to fix; see comment
    6
    for pointers. Ignore the other patch; it was just a
    workaround for gedit, but this bug will affect lots of apps.

  • Bug
    335524
    — Warn when apps set WM_TRANSIENT_FOR to a
    non-top-level window

    You just need to detect if an app sets an invalid hint (which
    should only be 1-2 lines of code, I think; see comment
    9
    for pointers). Then spit out a warning in that case.

Appeasing the Army of Angry Pitchfork Wielders

So, with approval from the release team and translation team, I
applied Ron Yorston’s patch to revert
Metacity’s focus behavior
to what was found in Gnome 2.12. I know
many of you were up in arms about this, with some
even considering torture
(though not as severe as what my 3
year old demands
). But it’s all better now, or at least will be
when I make a new release in a day or so (so that translators have time to update). 😉

When I mentioned that I should be publically whipped for needing
permission to break multiple freezes so late in the cycle, Clytie
helpfully pointed out that it
could be a good fund-raiser for Gnome
. While tempting, I have to
say that marketing and fund-raisers have never really been my thing.
For some odd reason, I think that this won’t be changing any time
soon. 😉

Now,
for
all
of
you
many
people
out
there
who
do
not
like
it
when
a
new
window
gets
focus
by
default: don’t worry; all you need to do is run

gconftool-2 –set /apps/metacity/general/focus_new_windows –type string strict

Bonus points to the first person to extend gTweakUI to include this
option (and the raise-on-click/orthogonal-raise one).

Hacking the bugzilla

Finally got some time to do some bugzilla hacking again. Probably should have spent the time testing the 2.14.1 release, but… 😉 Anyway, I killed various annoying behaviors — default to reopen needinfo bugs, reassign product and component requires two steps, triaging quick links only available on some of the relevant bugs, mass reassign bugs without spamming script only handles assignee, people are adding keywords without getting consensus on bugzilla-devel-list/bugmaster (fixed by adding an ominous warning to editkeywords), and a couple other odd ends.

Doing this work, I want to echo the most common thing I’ve seen in #bugs over the last several months… Whoever the telco is that is responsible for still not having fixed Olav’s modem yet so he doesn’t have an internet connection at home: DIE YOU SCUM. We want our bugzilla hacker extraordinaire back.

Avoiding kidnappers; a few rocking contributors; etc.

Thwarting abduction plots

Olav is pretty persistent, isn’t he? Sounds like there may be some co-conspirators in the plot as well. Although such plans would nicely take care of travel expenses for me, I’m thinking maybe I should put some plans together to go and request some official funding in order to be able to travel more comfortably than I assume normal abduction experts would provide. 😉 …even if it does mean a freakin’ long flight and lots of pain to get a visa or whatever is required. 🙁

Of course, this means coming up with something to present. And, unfortunately, I don’t know how long I have either as that site makes the annoying mistake of not specifying at what time on March 31st that abstracts are due (what? me procrastinate? Never…). So I’d have to do that soon, but am not sure what to cover. Jeff suggested something about how to file more useful Metacity bugs, but I don’t really know how to address that (or at least not enough for a significant talk) since most stuff beyond the basic guidelines often involves code familiarity. It could be cool to do something on Gnome Bugzilla, though Olav would be the more obvious choice for that (maybe we could do a joint presentation though). I’m really not sure what people would want to hear though, having been one of those slackers that hasn’t made it to these conferences before.

Are there things that others are interested in hearing about from the areas I work on? Are there any in particular that would be good for joint presentations or workshops (my talks and lectures tend to be very dry so you’d probably want them to be joint in some way to avoid such pain) My bet: With such a freakin’ long blog post like this, no one reads this and therefore no one responds, and I get to spin it and claim that there wasn’t any interest after all. 😉

Keeping up with BJörn and Thomas

BJörn and Thomas have been lighting bugzilla up with metacity patches. It’s been very cool, though a bit hard to keep up with them at times. 🙂 BJörn even started helping review other patches which is awesome. Now, if I can get Thomas to do that too… 😉 Søren has also been plugging away doing all sorts of work on the compositor, and I think between the three of them, Metacity 2.16 is going to seriously rock — lots of old bugs being exterminated and much OpenGL coolness. 🙂

Random odds and ends

  • Looks like I’m now syndicated on the new Utah Open Source Planet. Hi everybody.
  • Finally, at long last, I got the paper on unconditionally stable discretizations of the Immersed Boundary equations finished and submitted. Yaay!
  • Finally caught up on part of the backlog of important emails I have. Still have a bunch. I’m kind of embarrassed that some requests for new modules in bugzilla have sat for so long with no response, among several other things. 🙁

Is window moving/resizing/minimizing actually faster in Gnome 2.14.0?

According to this review of Gnome 2.14.0

Metacity’s most noticeable improvement is its speed — specifically, a faster redraw of windows when they are resized, moved, or minimized.

There were some changes that should have made it a little faster in 2.12, but the article seems to be contrasting 2.14.0 to 2.12.x. If the reviewer was using AIGLX or GLX and the compositor that’s part of Metacity or Compiz then I would know exactly where this claim is coming from, but it doesn’t look like he is using either from reading the rest of the article. So, I was actually surprised at this claim. I had previously been worried that I had actually slowed it down a little with my changes — but this is definitely making me feel better 🙂 Now, there were a lot of changes that affected moving and resizing, but did they really make that much difference? Or is this an underlying speed increase from pango and gtk (which we use to draw the frames), and I just didn’t notice because I got the small incremental improvements as they were made when Federico et al. beat the performance problems out of those libraries?

While I’m on the subject of Metacity, I recently came up with a highlight list of improvements over 2.12.x, and I thought others might be interested in it:

  • Edge resistance when moving windows (not magnetism; too bad I didn’t notice this mistake in the release notes until too late)
  • Dozens and dozens of moving, resizing, and placement bugs fixed
  • Raise-on-click is a pref now for all you mouse/sloppy focus users
  • Display hostname in titlebar for remote X clients
  • Fixed multiple bugs with multi-head support (which probably eclipsed the xinerama bug fixes done)
  • Real vertical and horizontal maximization exist now
  • Make Alt-Esc really behave as “switch between windows immediately” including showing minimized windows
  • Don’t allow focus stealing from terminals (sadly, some consider this a misfeature; will probably be an option in 2.16.x and be off by default — hopefully that won’t disappoint a certain LWN editor)
  • Real support for –disable-gconf for e.g. embedded systems
  • An –enable-compositor mode that should be workable “if you’re the right kind of person”; not built by default (however, it will be compiled in to FC5 and enable-able & diable-able on the fly with gconf though…)
  • Tons of other miscellaneous bug fixes

Smoketesting Gnome 2.14.0

Want to be the very first to have built Gnome 2.14.0 and try it out to see all the coolness it packs? Well, considering that it’s already more than a few seconds after 23:59 UTC Monday, you’re probably too late to beat seb128. But, he’s not exactly mortal as far as building packages goes, so he shouldn’t count. 😉 Be the first on your block, or maybe even country to try it out. Help us make sure that no nasties crept in. Cure World Hunger. Save the planet. Or something like that.

Vincent has put together a page explaining how to help smoketest the release. Go do it. Now.

Um, I meant back when you read that previous sentence. But if you mend your ways, now should be good enough. 🙂

Hackergotchi

Wow, it amazes me how quickly people are able to do hackergotchi’s. I just checked my comments after posting yesterday, and four responses had been gimped up — from “nibblesmx”, “mhitka”, Einar Jørgen Haraldseid, and Jakub Steiner. Thanks everyone! I had my wife look at them and choose her favorite. She picked this one: