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.

Tabs

In the comments to a previous post, we were asked about implementing tabs in the window manager.  Calum pointed out that the HIG recommends against applications adding their own document-level tabs on the grounds that this is a job for the window manager.  Yet the window manager has never risen to the challenge, and very many applications do in fact implement document-level tabs.

Implementing this will fall into three parts:

  • there must be a way of identifying groups of windows which may be tabbed together (we might, for example, use WM_CLASS);
  • there must be a display listing all tabs in the window border below the title (in a first revision, this could perhaps be done using the system menu);
  • there must be a mechanism for unmapping all but the selected window, and, when appropriate, for reconfiguring the unmapped windows to match the mapped window (that is, when the mapped window is resized or moved).

There have been some volunteers willing to do the work in the past, but no word yet of working code.  It should be a large piece of work, but not a monumentally huge one.  Again, if anyone wants to help now, abundant assistance is available; this may be something the maintainers could work on, but not until the bug queue has been reduced a little more.

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

Snap

ooooh, snap (peas), girlThere has been some discussion on the last post about implementing functionality similar to Microsoft’s “Aero Snap”.  Your chronicler has never used Windows 7, but the idea is demonstrated in this video.  It appears to mean that:

  • when a window is dragged to the left or right of the screen, it is vertically maximised, and resized horizontally to half the screen width;
  • when a window is dragged to the top of the screen, it is maximised;
  • there are hints elsewhere that dragging to a corner minimises, but this is unconfirmed at present.

There are apparently several people who would like this implemented on the free desktop.

One option is to do it with an external tool.  This is the route taken by this tutorial by gotsanity.  It’s a simple matter of monitoring the root window for configure events; the link goes to a program which will demonstrate the general principle.  Making that program into a daemon which will solve this problem is only a matter of adding code to detect a window crossing screen borders, and some kind of payload for when one does.

The advantages of this approach are:

  • that it will work with any window manager, and
  • that we have previously said that almost anything which can be implemented externally should be, to preserve the lightweight nature of Metacity.

The disadvantages, however, are:

  • the need to keep a separate daemon running; this is a good deal more of a long-term problem than launching one-shot processes on a keystroke,
  • the difficulty in adding the grey box that tells you you’re about to trigger the effect (though this is certainly not impossible with such a method), and
  • the change in the moment of triggering from after you release the button to during; this is a side-effect of the modern ability to drag a window itself rather than a wireframe.  It would be hard to solve in any way that didn’t feel like a hack.  strokinder points out why this is problematic.

The ability could also be implemented within the window manager itself.  The advantages and disadvantages of this plan are mirror images of those of the other plan.  It may, however, be worth the added complexity.  Additionally, the loss of the portability inherent in using an external script may not matter: if this was implemented in Metacity itself, it would presumably be fairly easy to carry it over to Mutter, since in this area the systems differ little.  Porting to Compiz may be more of a difficulty.

If anyone with a little programming experience would like to volunteer to work on this, abundant help can be provided; otherwise we will see about dealing with it when the bug queue is reduced a little. Please follow GNOME bug 607694, where this issue is being discussed.

Photo © Darwin Bell, cc-by.

Expansion and external tools

So I bought a flash...In GNOME bug 517722, a new keybinding is suggested which will make the focussed window take up as much space as possible without covering any other window.  If applied to all windows, it would make Metacity behave like a tiling window manager.

The main problem with this idea is the same one we were discussing almost a year ago: the same action can fairly easily be done using an external script and the EWMH.  So on the face of it there doesn’t seem to be much reason to add it into the window manager as well.

Of course, this could also be said of several of the less-used bindings, such as “move to southwest corner”.  Indeed, some have called for major keybindings such as alt-Tab to work this way.  The problem here is that external scripts are slow to start when the computer is overloaded: it’s important that alt-Tab keeps working even when the system load is high.  The same thing can’t be said of “move to southwest corner”, though.

Window managers which incorporate a programming language don’t have this issue, since a keybinding can be easily written to reconfigure a window in any way the user pleases, assuming the user is a programmer.  But Metacity aspires to be a lightweight window manager, and so does not provide this.

Both of these are reasons why your chronicler is not minded to accept this patch.  Perhaps both of these are arguments for moving keybindings such as “move to southwest corner” out to an external script as well, although we could say they are grandfathered.  Perhaps also there should be a general policy against anything that can be done in an EWMH script being accepted into Metacity in future.

The number of external EWMH scripts to do this kind of thing continues to rise. Mikkel Kamstrup Erlandsen has been working on putting a number of them together, including one to expand windows, and calling it WinWrangler.

Photo © widdowquinn, cc-by-nc-sa.

Border widths under user control

halfsiesAt present, the width of a window’s border is decided by the current theme.  However, some people find it harder either to see thin borders or to click on them.  They would prefer thicker borders than most people want.

In addition, Metacity measures border widths in pixels.  The higher the resolution of a display, the thinner the borders will appear, exacerbating the problem.

Of course, since borders are under theme control, one solution is to make a new theme; this is after all what we do for users who need high-contrast window borders.  However, this modification will need to be made for every theme a user wants to use.  Furthermore, the Metacity theme format is not easy for the general public to modify.

CSS themes would circumvent the problem by allowing widths to be specified in millimetres, rather than pixels.  However, this is not currently supported by the underlying libraries, and even if it was, the problem of themes which still used pixels would remain.

GNOME bug 496536, which mirrors Launchpad bug 160311, discusses this issue.  Two suggestions are made:

  1. A setting to allow the user to override the width of borders.  There is a patch to allow this, but it has not yet been committed. For example, here is the Crux theme with the border width set to 100 pixels.
  2. Make “the mouse stick to the border”.  If this means making the cursor pause briefly while moving over the border of a window, it may pose a problem with implementation.
  3. A third suggestion, not made on either bug, is that the clickable area of a border should be a few pixels wider than its visible area.

Your chronicler would like to hear from readers who have this difficulty, particularly because of an accessibility problem, as well as your opinions on what should be done about the matter.

Photo © Lauren Marek, cc-by-nc.

Metacity Journal 2010-01-18

Green JackThomas has been working on Metacity this past week, supported by Collabora Ltd.  Thanks, everyone!

A. Last week. Work on Metacity has fallen into three parts over the last week:

A1. Routine work such as reviewing patches. This included

  • GNOME bug 598231 (null dereference in visual bell).
  • GNOME bug 336750 (potential DoS on shift-printscreen).  This patch looked correct, but in testing it didn’t solve the problem; I am still trying to find out why.
  • GNOME bug 604897 (session management issue)
  • GNOME bug 592940 (markup in translatable strings)
  • GNOME bug 530702 (Metacity stops Compiz from starting up). This appears correct, and certainly fixes a bug, but I cannot test whether it fixes the presenting problem; can someone confirm?

A2. Cowbell (CSS themes). I have been working on merging the cowbell branch with the main branch, but this has been slow going.  I am wondering whether it would have been better to move all the Cowbell-specific code out to a separate library so that it could be called from other window managers as well; it would be quite a challenge to make it abstract enough.

A3 . GNOME bug 531512 (EWMH and D-Bus).  What began as a brief comment to a bug turned into a blog post, which turned into a script, which took a fair chunk of the day to get working.  But it does demonstrate that the idea is sound, and I’d rather have working code than hand-waving any day.

B. Going forwards.

B1. Bugs. There are still more bugs than can be reasonably dealt with by your chronicler.  This is important, because it looks like Metacity is here to stay after all.  Therefore:

  • Most of all, I need your recommendations as to which bugs should be dealt with first.  Obviously there’s the bug’s priority to decide this already, but I know there are many little things that get under people’s skin (Launchpad bug 160311 springs to mind).  I’d like people to nominate their least favourite bugs.
  • Also, I would like some help with patch review and the very inglorious Bugzilla work.  If anyone’s feeling like volunteering, let me know.
  • I plan to work out some kind of GNOME Love-type mentoring scheme where people get help learning to keep a project going.

B2. Cowbell: separate library?  I’ll think about it.  If you know someone from another WM who would also be interested in integrating such a library, let me know.  If you believe it would be better for the spec to be shared but not the code, let me know as well.

B3. EWMHbus: worth extending to a full set of EWMH abilities?  Worth rewriting in C?  Would anyone really use it?

C. Other things

I used to have a script which wrote most of the Metacity Journal for me, and it would include mentions of Metacity on blogs, and translation commits, and so on.  That script has rusted, which is a shame; maybe I should bring it back and generalise it so other projects could use it.  Several translation commits were made this week, anyway.  Thank you all.

Photo © Bushtick, cc-by-nc-sa.

Bad Behavior has blocked 127 access attempts in the last 7 days.

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