How to help with Metacity

Never turn your back on the fire...Someone was asking how they could help with Metacity. Here are some thoughts.

Why it’s important.  Metacity is (for now) the official window manager of the GNOME desktop.  Even though Metacity supports compositing, one of its strengths is that it can also run in a non-composited mode: plenty of people run Metacity who can’t or don’t want to run a compositing window manager.  Then there are the people who use Metacity in compositing mode because they prefer it that way, often because Metacity’s maturity gives it the edge over other window managers. Even after Mutter becomes the official window manager, Metacity will remain important: the core of Metacity is the core of Mutter.

Things you should read.

What needs doing. Metacity is a mature system, coming up to its ninth birthday, so there isn’t much new development to deal with.  Day-to-day work falls into one of these categories:

  • Triaging new bugs.  A bug is either a report of breakage or a request for an enhancement. Bugzilla will show you a summary of current bugs. There are a lot of them.
  • For reports of breakage, writing patches. This is really important.  If you’re looking for something to work on, try searching for the “gnome-love” keyword in Bugzilla.  This is used to mark bugs which are particularly suited to being fixed by newcomers to the project.  There are currently six of them.
  • For enhancement requests, deciding whether they should go in or not.  Usually the answer is “not” (see Havoc’s policy document).  This kind of bug has traditionally been discussed in a “bug of the day” feature here on the blog, but this took more time to write than it took to fix bugs, and so it’s been quiet recently.
  • For enhancement requests which should go in, writing patches.
  • Reviewing those patches and deciding whether they should be committed.
  • Making releases.

New developments. But if it’s new development you want, you might be interested in helping out with:

  • Mutter.  This is the forthcoming window manager and desktop system for GNOME 3.  It uses Metacity as its core.
  • Cowbell. This is an attempt to reform the recondite window border theme system into CSS, which is much simpler to understand.  This is stalled for the moment for lack of time and direction.

Photo © Chris Dixon, cc-by-nc-nd.

Plans for May

Bournville Maypole: The ChainI want to apologise to all the people who have been waiting on Bugzilla recently, especially to those of you waiting for patch review. There’s a terrible mountain of work to do, and few people doing it, and I’ve had a lot of my time taken up writing a book. But none of that is any good excuse.

My heartfelt thanks go to Owen Taylor and others who have stepped in to review some patches.

Here are the patches processed so far today:

  • GNOME bug 611260 – a simple patch to remove a warning for pedantic linkers
  • GNOME bug 577576 – Metacity was reporting a warning where there should not have been one
  • GNOME bug 570275 – this seems to be Subversion-specific and is presumably no longer relevant
  • GNOME bug 609502 – a crash in some circumstances retrieving a string list from gconf.  This appears to introduce a memory leak; asked patch author to reconsider this.
  • GNOME bug 565540 – Metacity doesn’t refresh keymaps when XKB refreshes.  Definitely a problem.  Owen reviewed someone else’s patch; I attempted to fix that patch to meet Owen’s objections.
  • GNOME bug 573922 – when there are two timestamps we could use for a window, use the earlier one.  This fixes a Nautilus issue.
  • GNOME bug 531012 – small memory leaks
  • GNOME bug 572332 – removing more deprecated symbols

There are about fifty bugs with patches remaining for review, and I’ve decided that this is my priority for May. By the end of the month I’d like to have reviewed all the patches. After that, I’ll go through and triage everything, and post the results here. One day, I’d like to get the bug count down to zero, but that clearly won’t happen this year.

Photo © Pete Ashton, cc-by-nc.

Theme-based button layouts

day 80Some window border themes, such as Radiance Chrome or any theme attempting to recreate the look of OS X, have the window buttons carefully designed as separate images which can’t be re-ordered without breaking the design.

At present, the order of buttons is under the control of the user, not the theme.  If a theme artist creates such a theme, they must tell the users separately to set the button_layout key in GConf to whatever is needed.  This problem is particularly acute because Ubuntu 10.04 Lucid Lynx uses such a theme by default, and accordingly sets button_layout to an unusual value; see Launchpad bug 532633 for much more discussion of this matter.  Users of Lucid who switch to other themes will still find the buttons arranged as before, which may confuse them.

GNOME bug 613522 suggests solving the problem by allowing themes to specify an override for button_layout.  This may be a workable idea.  However, according to policy, once a version of the theme format is released, it’s set in stone. So we can’t add new information to v2 themes: we can only move up to v3.

One possible workaround, however, is to allow a GKeyFile in the theme directory which specifies only the new value for button_layout:

[ButtonsOverride]
button_layout = menu:minimize,maximize,close

That would allow newer versions of Metacity to honour the layout request while allowing older versions only to honour what’s written in the theme file.  Gentle reader, what are your thoughts on such a scheme?

Launchpad bug 542772 is another attempt to deal with this problem, by adding an option to the window menu to choose the layout.  However, this is unlikely to be implemented: the window menu is already cluttered, and besides the button layout is a matter for gnome-control-center to decide.

Photo © kygp, cc-by-nc-nd.

Bug of the day: hiding “(as superuser)”

sulking HulkAs we mentioned the other day, there are some situations where Metacity’s ability to mark a window as running as root is unhelpful. One of these is during installation: this naturally runs as root, but it baffles new users to be told “Install (as superuser)“.

For this reason, GNOME bug 605137 requests a hint which can be added to a window to suppress this message.

Thomas has implemented this as the hint _METACITY_HIDE_USERNAME, and there is also a test case.

This patch may also be of use to other distributions, assuming we keep the “(as superuser)” ability at all– see GNOME bug 609431.  It may not necessarily go into the master branch, unless it would be useful to other people.  If it doesn’t, perhaps it can be a distro patch.

Photo © Sharyn Morrow, cc-by-nc-nd.

Bug of the day

Ladybird, ladybirdThere are several hundred bugs still open in the Metacity bug tracker.  Over a hundred of these are enhancement requests.

During the first quarter of last year, this blog ran a daily “bug of the day” or “squib of the day” feature, where suggested enhancements would be discussed.  Every so often, there’d be a roundup post where the fate of the bugs of the previous few weeks was revisited.  The idea was that decisions could be made in the open rather than behind closed doors.

That was all very well, and it got the community more involved in discussing new features.  However, there were two main problems:

  1. Enhancement bugs are probably the least important kind of bug, and yet they’re the most interesting to write about.  So this plan focused people’s attention on the least important things.
  2. There’s only a few people who are willing to hack on Metacity, and they only have a certain amount of time available to do it.  This plan meant that more time was spent writing blog posts than writing patches.

It might be useful to resurrect this feature, but not unless these two issues were addressed.  Perhaps we should extend it to covering all kinds of bugs in order of priority, and instead of having daily posts have a strict rule that nothing new could be posted until the previous bug had been dealt with.  Perhaps your chronicler should also delegate writing the posts, if some willing amanuensis could be found.

Photo © wiccked, cc-by-nc-nd.

“(as superuser)” considered harmful

It's not easy to be a superheroAbout a year ago, we considered the idea of showing the name of the user running a program in the titlebar, as suggested by GNOME bug 549389.  So if you were running Epiphany as user fred, and you yourself were not user fred, you would see “(as fred)” in the titlebar.  More commonly, if you were running Nautilus as root, you would see “(as superuser)” in the titlebar.

This eventually made its way to being commited to the master branch.

Various problems have since arisen:

  • Several people still say that it should say “as root” instead of “as superuser”.  The wording was chosen for fear that “root” was techspeak, but apparently “superuser” is as well.
  • gvim is somehow able to fool the user detection and displays “as superuser” even when it’s not.  Your chronicler suspects the EWMH properties are misapplied, but has not yet investigated.  This is Debian bug 549290, Gentoo bug 292517, and GNOME bug 603240.
  • Colin Watson has asked in GNOME bug 605137 for a way to suppress the message on particular windows, because the Ubuntu installer runs as root under Metacity, and the user doesn’t need to be worried about the “as superuser” part.  This is certainly something we can do, assuming we keep this feature at all.
  • Launchpad bug 519035 (which is GNOME bug 609431) says that any attempt to mark the titles of windows owned by root is “techspeak and ineffectual”.

We could:

  • keep things as they are
  • rename “(as superuser)” to “(as root)”
  • remove all visual indication that a window is running as root, but leave it in for running as other unexpected users
  • remove the patch entirely
  • replace the patch entirely with a way for themes to specify a titlebar style for windows running as root; this was GNOME bug 505157 and wouldn’t be very difficult with CSS themes (“frame[is-root] > titlebar { background-color: blue; }“).

Gentle reader, your opinions are welcome.

Photo © Esparta, cc-by.

Specifying button widths in CSS

The height of a button in a CSS theme is determined by the height of the titlebar, which in turn is determined in most cases by the height of the titlebar font, but occasionally explicitly.  The height of buttons cannot be set explicitly.

For the width of the button, however, there are two common cases:

  • The artist wants it to be a specified number of pixels, millimetres, ems, etc.
  • Much more often, the artist wants it to be a specified multiple of the button’s height, often 1:1.

There has been some controversy about how we should represent this in CSS:

  • In the first draft of the themes specification, the width and height properties could be set on a button, but were only used to calculate the ratio.  Explicit widths could be set using max-width and min-width.  Screwtape called this abuse of the semantics “a bit cruel”.
  • We could honour width directly for absolute values, but then there comes the question of how to handle ratios.  If you set the width to a percentage, we could use that, but traditionally that has meant a percentage of the width of the enclosing element, not of the height.  We could make an exception in this case, of course.
  • The universal solution of width: -cowbell-button-ratio(0.25), or whatever, which is ugly.
  • Or alternatively allow width to be set directly for absolute widths, and as an alternative have -cowbell-width-ratio: 0.25.
  • Invent a new unit!  width: 0.25ht.  This idea should probably be avoided.

Your chronicler is stumped as to the solution which would be clearest to theme artists.  Gentle reader, do you have a suggestion?

Themes roundup

Here are four pieces of news from the world of theming.

  1. Human may be replaced. We don’t usually cover news about specific themes here (although perhaps we should) but it’s worth noting that Ubuntu’s default theme, Human, although very beautiful, is a little long in the tooth.  There has been a proposal to replace it in 10.4 Lucid Lynx with a new, similar theme called Homosapien.  (Your chronicler notes that the human species is homo sapiens sapiens, not *homo sapien, and wonders whether it is too late to change the name.)
  2. Universal theme format. At present, there are scores of different formats for theming user interfaces, some of which are often packaged together to be complementary or alternatives. There are also various metatheme formats for packaging several disparate types of theme together, but they are specific to a particular desktop. David D Lowe has proposed a “universal theme format”, which is a container for various types of themes, to be considered as a freedesktop.org standard. Time will tell whether it’s adopted, but for the moment, gentle reader, you can find out the details in this PDF (there is no HTML version, unfortunately).
  3. The state of Cowbell. Speaking of universal theme formats, Cowbell is an attempt to allow theming using CSS rather than Metacity’s own rather recondite theme format, which may hopefully one day be picked up by other window managers.  More work has been done on the cowbell branch than has seen the light of day, but it has proved difficult to merge the existing content with the master branch; furthermore, we should probably be looking at keeping the CSS theme code separate in a library so that other window managers can use it as well.  So the branch has been quiet recently.  There are plans to forge ahead with what we have, however, and to integrate the results of the detailed discussion on the subject at the end of last year.
  4. Cowbell and its dependencies. There are several ways in which the current libccss-based implementation falls short of what we need, at least last time we checked. Any or all of these apparent problems may be mistaken, but:
    • Several of the CSS3 selectors which would be really useful weren’t implemented, even things like sibling selectors.
    • There’s also a lot of flexibility we don’t need, since our “documents” are of a fixed form.
    • There’s apparently no way to refer to a window’s icon other than by saving it as a bitmap and reloading it.
    • Some of the extensions we’d need to have equivalent power to the v2 theme system, such as -cowbell-replace-color, look like they’d be a nightmare to implement for similar reasons.
    • We can’t easily implement the requirement that it should be possible to load images from a tarball, for similar reasons.
    • We can’t easily add new colours, which we’d need to to implement system colours (which may be deprecated but suit our purpose very well), or any similar way of getting at the GTK colours.

    We could work around these, but it’s far better to make the theme format usable by humans than to tie ourselves in knots to get around infelicities in the software.  And we always have the option of adapting libccss to our needs.  But a lot of what we need to do is specific to our own case, and if this results in tying the library in knots it may become better to write a stripped-down in-house CSS parser that does what we want and is, as they used to say in Cambridge in the old days, BALGE: by and large good enough.

Gentle reader, we love your letters.  Let us know your news, whether or not it’s about themes.

Photo © camera_obscura, cc-by-nc.

Alt-Tab over all workspaces

Camille Flies HighAt the moment, when you press alt-Tab, you cycle through a list of windows on the current workspace.  People use workspaces in many ways, though; some people keep only one application maximised on each workspace.  Very many people have asked for the ability to alt-Tab between windows on all workspaces, not just the current one.

There have been many bugs raised about this matter.  One approach, taken in GNOME bug 577699 by Alexander Larsson, is to add a new keybinding called switch_windows_all, which can then be re-bound to alt-Tab.  This is certainly a possibility, but adds a new keybinding and a new GConf setting.  It is apparently how Compiz solves the problem.

A different approach was suggested six years ago by Havoc in GNOME bug 143511.  The window list in the panel has the option of toggling between a list of all windows and only the windows on the current workspace.  It is contrary to the principle of least astonishment if the windows listed in the alt-Tab display are not the same as those listed in the panel.

Therefore, the window manager should detect this setting in the window panel list and behave accordingly.  This could be done simply by reading the setting out of GConf.  A more portable way would be to have a new EWMH hint on the root window; however, this was raised on the wm-spec-list in 2007 and was not well received.  Generalising GNOME’s panel to all environments may be tricky.

Again, anyone wishing to work on this will have abundant help available; otherwise we will get to it when the bug queue is reduced a little.  GNOME bug 143511 is the one to follow.

Photo © Scott Ableman, cc-by-nd.

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.