Metacity Goals #2

So, the first round of Metacity
seemed to be pretty successful. Dan Sanders fixed bug 335076 (Maximizing and unmaximizing windows doesn’t raise them) and bug
(close-window verification dialog not shown when main window is minimized), while Thomas Andersen fixed bug 335524 (need to warn when apps set WM_TRANSIENT_FOR to an invalid window). Two other people found good starting bugs on their own; Brain Pepple added support for
from Gnome Goal #2
and Andy Morum fixed bug 336605 (needs to build with –disable-xsync). And I should mention that while new developers fix these tasks, Björn and Thomas keep plugging away fixing issues all over the map. And Soeren has been very prolific in providing a near constant stream of improvements while hacking on the compositor, but has kind of gotten the shaft limelight-wise, being co-maintainer and all.

So, here’s a new round of Metacity Goals. These are simple coding
tasks for those wanting to get started in Gnome. As before, 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. The second step is to pick a bug, and I have a few

First, the bugs that are still left from last time:

  • Bug
    — Support sibling from restacking ConfigureRequests

    This is just an unimplemented FIXME, basically. In the bug, I
    point out a section of code having stuff very similar to what’s
    needed to implement this.

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

    Has good steps to duplicate, and I provided directions showing
    where a similar bug has been fixed elsewhere to help you fix
    this one.

Plus a round of new bugs:

  • Bug
    — Can’t revert or undo either drags or resizes with
    the escape key

    There’s a couple steps to fixing this, but I outline them in
    the bug with pointers and all of them are pretty short.

  • Bug
    — Moving maximized windows from one xinerama to
    another broken

    Should just be a few lines of code, and I even point out where
    to look. Hurry, get it before someone else!

  • Bug
    — Missing synthetic configure notify makes windows
    walk up the screen

    This one probably doesn’t fit in this list, but I can’t resist
    throwing it in. It will probably be harder than the others,
    because I’m first asking that someone write a testcase
    displaying the bug (for both testing and patch verification

    If you can get that testcase written though, the patch to fix
    the bug in metacity is almost certainly a one liner (just
    making sure send_configure_notify() gets called when it needs
    to be). I’m even fairly sure which function needs to be
    modified (though it’s not exactly a simple function), so the
    big thing really is just getting a nice simple testcase.

  • Bug
    — constraints borkage with titlebar

    People can lose the titlebars of their windows, having them go
    off the screen. (oops! One more bug from the rewrite of
    constraints.c for Gnome 2.14…) Fixing this means writing a
    new constraint in constraints.c; I’ve outline all the necessary
    steps in the bug.

Those interested in getting started in Gnome working on some other
module, may want to have a look at the Gnome Goals, bugs in
bugzilla marked as being suitable
projects for new developers
, and other general information on the
stupidly-named GnomeLove
page containing information to help you get started.

Metacity 2.15.0

Metacity 2.15.0 has hit the streets as part of the new Gnome 2.15 development series. I’m particularly pleased with this release, because we have contributions from nearly a dozen different people, and the only thing I did was one measly trivial fix. :-)

  • An endless array of compositor updates, not all of which are
    well explained in the ChangeLog. ;-) Includes an ability to
    enable and disable the compositor at runtime, fixed up wobbling
    effect and new explosion effect, special magnification handling,
    different opacity for different window types like menus, a way of
    scaling windows, handling of foreign displays, improved handling
    of window moving/resizing, various code restructuring, special
    runtime checks for correct extensions and other compositors, lots
    of bug fixes, and possibly other stuff I’m missing or not
    understanding (Søren)
  • Removed “move to another workspace” menu when there are exactly
    two workspaces (Thomas) [#151183]
  • fix type for compositing_manager schema entry (Elijah)
  • Port more properties to our async system for code cleanliness
    and speed improvements (Havoc, Thomas) [#309567]
  • Lots of code cleanup, even more code cleanup, wow our code was
    messy (Björn) [#335177, #337507, #336890, #338359]
  • Abstract out the functions for setting/unsetting demands
    attention hint and avoid doing it when the window isn’t obscured
    (Thomas) [#305882]
  • Change strings to make them more readable, and more
    translatable (Gora Mohanty) [#335720]
  • Reduce compiling warnings — add a number of casts and change
    signedness on a number of variables (Björn) [#336032]
  • Fixed broken links in README (Alejandro Andres) [#333303]
  • Add a tabbing function, bound to alt-f6 by default, to cycle
    through the windows of the current application (Thomas)
  • Fix the build with –disable-xsync (Andy Morum) [#336605]
  • Raise windows on maximize/unmaximize (Dan Sanders)
  • Don’t have confirmation windows make applications appear to be
    locked when closing via the window list (Dan Sanders)
  • Allow more than one keybinding for any action, by checking
    a gconf key of the form <foo>_list where <foo> is the gconf
    key giving the first/normal keybinding for that action. (Thomas)
  • warn and ignore if transient_for is set to a non-top-level
    window (Thomas Andersen) [#335524]
  • Use po/LINGUAS for listing supported languages (Brian Pepple)
  • Nearly 3 dozen language translation updates

Enlightening mankind about the correct spelling of Gnome

Alan Horkan had some very
enlightening words worth repeating for all of you out there who misspell ‘Gnome’:

We know you like Gnome but there is no need to shout.

Okay if it is an acronym then the only correct way to write it is G.N.O.M.E. and then it looks strangely reminiscent of a James Bond villian. If that is too difficult for you to type then by all means type “Gnome” and stop inflicting ALL CAPS on people.

R.A.D.A.R. and L.A.S.E.R. stopped being treated as acronyms and I look forward to the time when Gnome is mature and popular enough to do the same.

GUADEC ‘n stuff

Finally got registered for GUADEC yesterday, and got the flight plans and lodging taken care of (just in time, too). A big thanks to Quim for the huge amount of work he’s putting into organizing GUADEC…and for showing superhuman patience with me and my dumb questions (especially the repeated ones). :-/ Deborah usually doesn’t like me being gone for very long, so I was wondering what she was going to say when I told her how it was, uh, longer than expected. In her fairly typical style, though, she brushed off her preferences and instead encouraged me about the whole thing. She’s so cool. :-)

I also got my passport application done today, and was a bit surprised by its cost; I guess it’ll probably have to count as much of my birthday present (several months early) this year or something. I also didn’t realize that the birth certificate had to become part of the application instead of just being shown to the relevant people. Annoying, since I only had that one copy. Do they send it back after processing the application, or do I have to try to get another one from somewhere? I guess I should have asked when I did the application, but between moving around for pictures and other interruptions during the process (mainly from other people who had questions while filling out the forms), I forgot about it at the time. *sigh*


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
(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
    — Maximizing and unmaximizing windows doesn’t raise

    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
    — 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
    — 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
    — 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
    for pointers. Ignore the other patch; it was just a
    workaround for gedit, but this bug will affect lots of apps.

  • Bug
    — 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
    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. ;-)

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.