2007-11-16: “Higher standards of elegance”

There was some discussion over the option on the window menu which controls the attribute known to the developers as “stick”. This makes the window follow you around when you move workspaces; it’s useful, for example, to keep a clock applet always in the corner. Some people think that the window menu should have two options for this, and some people think that that is a waste of space, and not elegant, and rather it should just have one option which toggles. In that case, however, it’s not very clear how to word it: someone has suggested “Always on current workspace”, but what does it mean when that’s turned off? “Never on current workspace”? “Sometimes on current workspace”? The Human Interface people were helpful here.

Speaking of human interfaces, apparently now if you select the High Contrast Inverse theme, Metacity colours certain icons on the window menu a tasteful shade of black on navy. I think we need to get to that soon before Trinny and Susannah track us down.

Some people on Launchpad would like to be able to resize by dragging using mouse buttons other than the standard ones, because they don’t have a middle button.

And Benjamin submitted a patch for the theme directories problem which (informally) looks good. Unless anything particularly odd shows up in it, it should go into the next release, expected some time early tomorrow morning Greenwich time.

Photo: The Crown, St Albans. Photo by Gary Houston, public domain.

2007-11-15: xterm, glib, api

xterm has a habit of padding the bottom of the screen in unsightly ways, apparently (your chronicler always uses gnome-terminal). It was suggested that this might be solvable in metacity, but it’s not at all clear how the details would work. (Finding the bugs where this was discussed before would be useful.) Havoc pointed out that xterm is as patchable as metacity is.

Benjamin Gramlich submitted another version of his well-written theme-finding patch, only to have Havoc suggest that g_get_system_data_dirs() would do a lot of the work for him; Benjamin is now away rewriting the patch in terms of that function.

Thomas deleted api.[ch] because it was never used.

Your comments and suggestions about any of these, or anything else related to window management, are welcomed. As the header now says:

There will be links to discussions, and you should feel free to dive in. We might link to Bugzilla discussions, discussions on the various downstream trackers such as launchpad, news coverage, or random blogs. (If you mention Metacity in your blog, we will get to hear about it, and we might link it and discuss what you say.)

Today in the blogosphere, Harsh shares how to turn off the window minimise animation using gconf-editor, Opera Omnia told us that Metacity was not at all outdated, and elsewhere there’s some more talk from people who are switching back to Metacity from the default window manager in Ubuntu Gutsy: László at length on why he’s doing so and Magpie on how to do it (I believe there are actually easier ways, but I’m not currently running Gutsy, so I don’t like to comment).

A development point release is planned for Sunday (but might happen on Saturday, depending on workload).

Photo: The Rat’s Castle, St Albans. Photo by Gary Houston, public domain.

2007-11-14: a quieter day than usual

The VintrySome helpful Ubunteros came and fixed Thomas’s laptop, which meant that Benjamin’s patch got reviewed (good work there), and also that the question was raised about what api.[ch] are good for.

Most of the checkin activity today was from Iain Holmes with his new compositor rewrite (or, as he has called the branch, the Bling-Tastic Bucket o’Bling). I am hugely excited about this; I hope Iain will write about his experiences here later.

On Launchpad, a discussion has been going on about whether it should be possible to set the width of window borders in general rather than its being down to the theme. Having too-narrow window borders makes resizing windows difficult, but some people don’t like the way it looks. This briefly spilled over into GNOME Bugzilla. It would seem to be a good plan to ask people to make default themes have large borders.

Alex Turner identified a place where the code could be made clearer and more easily optimised by the compiler, which seems promising.

A few months back, Matt Harley wrote a post about why he’s running Metacity rather than Compiz, which should be interesting reading for the future if we want to know why people choose Metacity rather than any other way of managing their desktop. Gentle reader, if you do, why do you use Metacity?

Photo: The Vintry, St Albans. Photo by Gary Houston, public domain.

Version numbers (and automatic hyperlinking)

A short note about Metacity’s version numbers: they are of the form major.minor.point, as with most software these days. “major.minor” tracks the GNOME release they belong to; thus major will probably be 2 indefinitely and minor will increase by 2 every six months, using the convention laid down by the Linux kernel of using the odd number as the unstable branch and the even number one lower as the stable version into which only bugfixes will go. The first version of Metacity was version 2.3.

The point numbers mark individual releases; they iterate over the Fibonacci series, beginning at F2. (The point numbers of GNOME as a whole iterate over the natural numbers.) There should be at least one Metacity release just before each GNOME release, and at least one every fortnight or so. The main version currently under development (“trunk”, in Subversion language) identifies itself with the version number of the next unstable point release.

Automatic hyperlinking: I will be writing a script which takes text about the day and posts it here. As part of that, I would like to hyperlink names of contributors (including translators!) If you’re likely to be mentioned here and you have a website, let me know what it is.

2007-11-13: largely about raise-on-click

Duke of Marlborough, St AlbansMore Metacity goings-on for 13th November. Apparently, for some people, no window has focus immediately after login, which causes screen readers to get confused. This has the potential to be an interesting bug, because it concerns the interaction of Metacity, X, and screen reader software, any of which might have been customised in interesting ways for a particular distribution. The original reporter says he won’t be able to follow up for a few weeks, though.

Unfullscreening windows which believe themselves to be as big as the screen anyway causes a workaround to be triggered and the window is returned to the fullscreen state; this is a regression from 2.18. Thomas is looking into it (though not very immediately because of a broken laptop).

Peter Bloomfield committed his fix that windows should not remember their positions while maximised.

Some small amount of raise-on-click controversy. There is an idea that which windows get put on top should be between a user and their window manager, and in particular that applications should not get to force this on people. This gets patched downstream— a lot– and there is a general policy that things which get patched all the time downstream should be patched upstream too. Some people are asking for changes in the way this alteration is made; the present writer is not on top of all the issues and should probably not attempt to explain just at the moment. Also, the historical lack of a unique-app ability in gtk is causing authors to use workarounds which then break WM standards (and again).

Someone complained that metacity does not set focus when it is forcibly killed; the reason anyone would care about this turned out to be that another program called ROX-Session has a method of setting the window manager involving killing the old window manager, whereupon a dialogue comes up asking which new one you’d like. Of course, by that time, you can’t switch to the new one anyway because you have no window manager.

The previous discussion about unidirectional maximisation slowed down a bit, with a discussion of code rot in alternative patches which aren’t (or aren’t yet) accepted into trunk. (The grandfather example of this is probably the double-click to close patch.)

Thomas’s patch review plan continues with a promise to review this patch about the location of user themes, but, again, the broken laptop has put that on hold for a few days.

Photo: Duke of Marlborough, St Albans. Photo: Gary Houston, public domain.

2007-11-12: mostly going in just one direction

Hare and Hounds, St AlbansIt’s been a busy day here in the Metacity bug tracker, so I thought I’d make a summary of the discussions happening around the table. Feel free to drop by any of them and weigh in.

Unidirectional maximisation continued to be a controversial topic. A while ago, we added the ability to make a keystroke maximise a window in one direction only. Some have said this feature is useful; others have said it is crack. Those who said it was useful also said they would like to be able to do so using middle and right mouse clicks on a button, as in some other window managers; those who said it was crack pointed out that this was inconsistent, since there was no obvious way to make the visual user interface show whether a window was already unidirectionally maximised. Various patches were posted. Codebase forks over the matter were suggested. It was decided that a gconf option to control this would be a bad plan. The idea of a “traditional Unix users” control panel to keep all the crack together was raised, which not only raised the spectre of allowing the crack in by the back door but also required getting control-center maintainers to co-operate. No consensus has yet been reached.

In other news, discussion continued about how to fix the bug fixed in the previous point release about not saving the coordinates of maximised windows; it needs to apply to fullscreened windows too. A success story: Federico and Elijah jointly found a fix for the problem about transient windows stealing focus. The dearth of themes which support version 2 of the format, which is required in order to display shade and unshade buttons on the toolbar, was shown by someone raising an enhancement request to be able to do so, although that veered off into discussing having a fullscreen button; naturally, such a button would be one-way only (since fullscreen windows don’t have titlebars) and would need to wait for version 3 of the theme format. And finally, this bug just arrived here from gnome-session.

Thomas is aiming to have all unreviewed patches reviewed within the next few point releases, since rather a queue has built up.

Photo: Hare and Hounds, St Albans. Photo by Gary Houston, public domain.

Release: 2.21.1

River Ver, St Albans2.21.1 was released last night; it had been held off a little because of a regression in #486445, which is now fixed. Therefore, more patches than I’d ordinarily have expected to go into a point release went in.

Thanks to Elijah Newren, Alex R.M. Turner, Peter Bloomfield, Iain Holmes, Jans Granseuer, Federico Mena Quintero and Thomas Thurman for improvements in this release.

  • Add –sync option, like all other GTK apps (Iain)
  • Don’t save window’s position if it’s maximised (Peter) (#461927)
  • Memory leak fix in preview (Jans) (#469682)
  • Truncate tab popup string correctly, and refactor function (Alex)
  • Windows which pop up under always-on-top windows don’t get the focus, but do get the “needs attention” hint (Thomas) (#486445)
  • Fix error in function call which caused focus problems (Federico) (partial fix of #488468)

Translations: Djihed Afifi (ar), Metin Amiroff (az), Alexander Shopov (bg), Jordi Mallach (ca), David Lodge (en_GB), Jorge González (es), Iñaki Larrañaga Murgoitio (eu), Vincent Untz (fr), Alastair McKinstry (ga), Ankit Patel (gu), Rajesh Ranjan (hi), auto (hr), Changwoo Ryu (ko), Raivis Dejus (lv), Wouter Bolsterlee (nl), Gora Mohanty (or), ASB (pa), wadim dziedzic (pl), Duarte Loreto (pt), Og Maciel (pt_BR), Peter Tuhársky (sk), Matej Urbančič (sl), Daniel Nylander (sv), Maxim Dziumanenko (uk), Funda Wang (zh_CN)

Source available here; md5sums are:
87d2a41d7bee2e52c627f3d6e4a7baf3 metacity-2.21.1.tar.bz2
0dec5b54b89603e9b7b3b98a7ad590da metacity-2.21.1.tar.gz

Photo: River Ver at St Albans. Gary Houston, public domain.

How Metacity creates an alt-Tab list

1926PepFrenchNovoTabsI’ve been asked to explain how to add new items to the list of programs which appears when you use alt-Tab to switch between programs in Metacity. This is a bit of a simplification, but it goes like this:

When the user is switching between applications using alt-Tab, Metacity has what’s called a “keyboard grab” on the X server. This means that it gets told about all the keyboard events, and no other X client hears about them. The grab is initiated by meta_display_begin_grab_op() and ended by meta_display_end_grab_op().

Everything Metacity needs to know about a screen’s tab popup is kept in a MetaTabPopup called “tab_popup” which lives inside the MetaScreen representing that screen. In a newly-created MetaScreen, it’s null, because there’s no popup on that screen. It gets initialised by meta_display_begin_grab_op() calling meta_screen_ensure_tab_popup() (or meta_screen_ensure_workspace_popup() if we’re actually needing to switch between workspaces, rather than applications), both of which call meta_ui_tab_popup_new() in order to actually allocate and initialise the memory.

Before it calls meta_ui_tab_popup_new(), however, meta_screen_ensure_tab_popup() needs to prepare a list of MetaTabEntry items to display in the popup. It does this by calling the function meta_display_get_tab_list(), which is where the magic truly lives.

meta_display_get_tab_list() returns a GList of MetaWindow objects. (meta_screen_ensure_tab_popup() converts the MetaWindows to MetaTabEntrys.) This is where the actual list of windows that you see when you press alt-Tab comes from.

Now, there are actually three kinds of list that meta_display_get_tab_list() might be asked for, and these are represented by the possible values of the MetaTabList enum parameter “type”. META_TAB_LIST_NORMAL means the ordinary alt-Tab sequence you’re used to, of ordinary user application windows. META_TAB_LIST_DOCKS means that what’s needed is a list of system windows; you can see this in action by pressing alt-ctrl-Tab. META_TAB_LIST_GROUP means that what’s needed is a list of all windows (even dialogues, etc.) in the same application group as the current window.

How do we deal with this headache-inducing complexity? meta_display_get_tab_list() does the sensible thing and delegates it (in this case, to a macro). It iterates over every window in the requested workspace and adds it to the result list if

  • it’s on the same screen, and
  • the IN_TAB_CHAIN macro returns true for it. We will come back to this in a moment.

The result list is ordered firstly by whether the window’s minimised (minimised windows come first, presumably because this is standard behaviour on certain other operating systems); after that, most recently used windows come first. You can verify this using alt-Tab on your own desktop.

The IN_TAB_CHAIN macro (in display.c) is written in terms of the three macros META_WINDOW_IN_*_TAB_CHAIN (in window.h). Each of these takes a single argument, a MetaWindow, and returns true or false depending on whether it’s in that particular tab chain.

The original reason I was asked to explain all this was a request to add all windows (on any workspace) which have the urgency hint to any newly-created tab chain. This wouldn’t be a suitable thing to add to the META_WINDOW_IN_*_TAB_CHAIN macros, because the list of windows passed to those is pre-filtered to include only windows on the current workspace. Instead, it should be added to meta_display_get_tab_list() as a separate, final step.