Thomas Thurman – Page 3 – …for the adult in you

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

There 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

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

At 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:

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.
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.
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

Thomas 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.

Window managers and D-Bus

D-Bus is the standard way for applications to communicate with one another. But the EWMH, supplemented for our purposes by libwnck, is the standard way for applications to communicate with the window manager. GNOME bug 531512 raises the suggestion that even window manager communication should be done over D-Bus, or at least that D-Bus should be an alternative to the EWMH.

There are two main questions to answer before we make any decision here:

Does this buy us anything? Are there people whose lives will be made easier if they can do what they want over D-Bus, without having to include X libraries to use the EWMH? Is this enough to justify the additional complexity in each window manager?
Can we keep this standard? EWMH works with almost all window managers. Switching to a D-Bus-based system brings the risk of fragmentation.

A third option: We could have a separate application which provided a D-Bus service that knows how to send and receive EWMH messages. Such an application could be run in conjunction with any EWMH-compliant window manager. Here’s a quick proof-of-concept your chronicler threw together in a few hours in Perl; let us know, gentle reader, whether you believe it’s worth developing any further.

Photo © Salim Virji, cc-by-sa.

Future directions of Cowbell

Future directions. Here’s where Cowbell is going next:

The existing functionality is going to be moved into a library called libcowbell. Very little will be changed at this point from what we already have. (But there will be some extra tests.)
A release of the metacity-cowbell branch will be made that can use libcowbell.
A release of real Metacity will be made that can use either libcowbell or conventional themes.
Development of libcowbell can continue. (I expect pseudoclasses to be among the first things added.)

More more cowbell. Iain has pointed out an existing GNOME-based project called cowbell. I hope the fact that this project will be libcowbell will be enough to avoid confusion.

Feedback on feedback. Screwtape has reviewed the existing cowbell documentation in a web page here. Here is my feedback on the feedback:

§3: I did start out by showing the structure as pseudo-XML, but people commented as if the window borders were the result of rendering that XML (as if it were XUL, or something similar), so I think it may be misleading.
§3: I dithered over using the ID or a class for this sort of thing for quite a while. In the end I went with a class because we use classes for buttons (since they may repeat) and it seemed as well to use the same design for areas, and because you may have more than one content area visible at once, even if they are on separate windows. But I may have been wrong, and I invite opposing opinions.
§3: buttongroup: I really like this idea. But AFAIK libccss doesn’t yet support last-child etc (see next…)
§3.1: I want our CSS support to be up to level 3 wherever possible. However, we are constrained partly by what libccss is currently capable of. Of course we can patch libccss too! Backgrounds and Borders is largely supported by libccss, though.
§3.2: Unpainted areas are transparent (though if the frame is opaque, you’ll just see the frame through them).
§3.3: font-size is important; what should the interaction be between the font size set in Metacity gconf and the font size in the theme? Just use the theme font size for scaling as in v2?
§3.3: button heights: I think I didn’t explain myself properly here. You can (should) set height and width on buttons. But these only serve to establish an aspect ratio. The height is always calculated from the titlebar height at present. Perhaps this is overly confusing.
§3.5: :focus pseudoclass: perhaps this should be set on all elements in a focused window. Or perhaps just the frame and we can use the descendant selector.
§3.5: :disabled — hadn’t thought of this, good idea. TMTOWTDI.
§3.5: I’m not sure libccss supports :not() (but maybe it does!) If so, yes, we should use it. It’s far better to work the way people expect us to work.
§3.7: I hope we support SVG too. It would be extra nice if it could be styled with the same CSS somehow.
§3.8: I really want mm and em as well as px. I’m not certain libccss knows how to do this, but I will check.
§4: Nobody’s really tried to put Dublin Core data in CSS before, and I’m probably not doing it the best way. I worry that including a required custom XML file will be slipping back into using custom formats, though. Maybe we should use an @rule. Or specially-formatted comments. Or maybe we should give up on the whole required metadata idea.
§4: I like the idea of specifying alternative stylesheets, though metadata in the stylesheets themselves could also do this.
§6.1: yes, we really need a default stylesheet. I’m not sure what should go into it. I will think about this and include it in the first libcowbell release.
§6.2: okay, we’ll avoid data: URLs.
§6.2: let’s implement the single file doctrine by allowing any file in ~/.themes/ThemeName/cowbell/ThemeName.tar to be treated as if it was in ~/.themes/ThemeName/cowbell/. I think we can get that in the first libcowbell release too.
§6.5: I really like Firebug. Are you thinking we could use Firebug itself, or just copy its UI?
§6.11: Maybe we could also modify hue/saturation/value directly in the URL thus: url(‘file:fred.png?hue=#f00’)?
§6.13: I was thinking of themes which, say, repeat a pattern an integral number of times on the otherwise empty part of the titlebar, scaled to fit; this wouldn’t be possible using border-images, but would work fine with filler. On the other hand, perhaps this is overkill.

Feedback from everyone reading this, on the above and on the original document, is very welcome.

Maybe we need to take over a little piece of live.gnome.org to hash all this out. Or maybe we need a mailing list. I’ll wikify all this tonight and then post about it here.

Future directions for Cowbell

I believe the best direction in the immediate future for Cowbell is as follows:

Fix the :hover and :active pseudoclasses.
Add support for v2 themes back in.
Provide a patch for Mutter.
Port some more themes, such as Crux.

Anyone wishing to advocate for anything else on the future directions list to come sooner is welcome to make their point, however.

Please let me know if you’re testing Cowbell, or if you’re interested in it. whether or not you’re working on new themes. I’d like to keep the Cowbell community cohesive.

The Sunshine theme

In order to demonstrate Cowbell more adequately, I asked Firinel to help design a new and simple theme. The result was Sunshine.

In order to test Cowbell, you will need to download Sunshine. Then follow the instructions in the README to unpack it into your ~/.themes directory. The tarball also includes a copy of Crux, so that you can share GConf settings between desktop Metacity and Metacity-with-Cowbell running in a Xephyr window.

I hope this new CSS theme is the first of many.

CSS on window borders experimental layout language

I’m happy to announce the first experimental version of Metacity with support for CSS window borders (“Cowbell”). This work was largely supported by Collabora Ltd.

You can:

download the tarball;
read the documentation (it’s not as boring as you might imagine);
review the source history.

This diagram should explain everything, perhaps.

I would especially like to hear from:

theme artists, to let me know whether it’s adequately powerful;
anyone else interested in hacking on this with me;
the GTK client-side decoration people, so that we can harmonise the way we represent things;
people who know a lot about CSS and can offer insights into the suitability of the way we represent things;
people who know a lot about the Dublin Core and can offer insights into whether our metadata system uses it appropriately;
maintainers of other window managers (especially Mutter), so we can talk about including CSS support in other window managers;
everyone else, to suggest which of the directions for future development are most interesting.

I think it may perhaps be helpful to set up a Cowbell mailing list, so that we can compare notes on implementations. For example, I haven’t written down anywhere how to place an image to the right of the title, which is commonly needed (you use border-image).