Now, we can imagine that any package might want to add menu options when it was installed, and delete them when it was removed.  Let us not concern ourselves for the moment with how a menu option and its effects are represented, other than assuming that it may be represented by an ASCII string. Rather, let us consider the ways in which a newly-installed application may wish to add menu options.  We are concerned with two kinds of menu option:

• ∀: these appear on every window menu, for as long as the application is installed.  It need not be running.  For example, Take screencast should be available when Istanbul is installed and removed when Istanbul is removed.
• ∃: these appear only on the menus of windows created by the application itself.  For example, Play should appear on Rhythmbox’s window menu, but not on other applications’ menus, even if Rhythmbox is running.  (Otherwise, how would a user tell the difference between Rhythmbox’s Play and the Play of Totem?)

Users should have the option of disabling any ∀ options which are currently installed; the full set of ∀ options would be available in some kind of settings dialogue where a decision could be made about which options belonged on the list.  It should be noted that Minimize, Maximize, Close, etc., are the ∀ of the window manager itself.

So, where should these settings be stored?

• In X properties on windows: The ∀ options would be stored as properties on the root window, and the ∃ options as properties on the windows involved.  This would be the simplest to implement, but who has the responsibility to set the property on the root window, and where does the data come from?
• In GConf: This would only work for ∀ options.  It’s presumably a better plan than keeping them on the root window, though, and we could still use X properties for the ∃ options.
• In /usr/share/applications/*.desktop: This is the way which would integrate best with package management, but would cause rather a performance hit as all the .desktop files would need to be scanned when the WM started up, and then there would need to be some kind of particularly clever window matching to work out which .desktop file corresponded to which windows for ∃.

Some kind of hybrid approach may be best: we could keep the ∀ menu options in .desktop files, and have a utility program that was run when any package was added or removed, to update GConf with the values.  Or perhaps this updating could be done in the control centre, when the user chose which subset of ∀ options they wanted.  Then we could keep ∃ options as properties on the windows, and rely on the toolkits to update them (perhaps even by parsing the application’s .desktop file).

Photo © van swearingen, cc-by-nc-sa.

The first question to resolve is how the interplay of element names, classes, and identifiers applies to us. For example, when styling the close button, is it:

• a button with id=”close”, or
• a box with class=”button” and id=”close”, or
• a close with no class or id attributes?

For simplicity, we went with the last option.  We represent the decorations of a window frame using a set of unique element names arranged into a particular hierarchy.  Almost every element is a simple box; the exception is title which is textual.

We use libccss to parse the theme and also to apply certain of the box styles; this means that this experiment is drawn using Cairo.  (It would have been possible but more complicated to use nbtk for styling, which would have meant this experiment used Clutter.  This is more probably what a final working result would be like.  An attempt was made to use nbtk but some of the more complicated styling options appeared to be currently unsupported.)

libccss supported background images and reasonably complex border drawing.  There were two things we needed which it did not (yet) support, so we had to kludge those in:

• text styling, for the title; we only bothered to implement justification.  Our approach here is to use a simple text label for the title and to style it, rather than using explicit vector graphics as in v2.  Effects like Human’s shadowing would be implemented by something like CSS3’s text-shadow.  More complicated arrangements like Atlanta’s centred icons would be impossible.
• the complete CSS box model; only borders were supported.  We made a half-hearted attempt to support margin, and did not even touch padding.  However, in so doing, we made…

A useful discovery: In doing this it became clear that there are two possible ways for a file format to describe vector graphics.  Either the position of everything can be represented using arithmetic expressions, which is how the current Metacity theme format works, or it can use a hierarchical box model, as HTML and CSS do.  One of our stated aims for v3 is ease of editing, and the box model appears to be a better fit for humans to understand in a drag-and-drop editor (as seen, for example, in Inkscape).  Therefore, if we do not adopt SVG or CSS for v3, it may be worthwhile to look into box-based layout models even in a custom format.

Here’s one draft of the CSS for Human, and the results of processing it with this hacky and experimental code are shown on the right (with the real thing around it for comparison).

Problems and challenges:

• New properties. We are certainly going to need to invent properties which are unheard of in real CSS. (For example, corners will need to indicate the degree of rounding.) These properties should probably be marked in some way. Mozilla marks its new properties with a leading -moz; perhaps we should do something similar.
• Dublin Core metadata. This could be implemented using custom properties on the toplevel “theme” element, representing the author, licence, and so on.
• Named colours (especially those which refer to the GTK theme).  libccss does not allow new colour names to be defined; perhaps we should ask for this.  On the other hand, it does allow new callback functions to be created, so that you can write color: gtk("bg-selected") or something.  This allows us to get the same effect at least within the CSS.  However…
• Pixmaps.  This system is well-suited to defining pixmap themes, which are at least fast, easy to understand, and simple to manipulate.  However, they are generally discouraged because they scale badly and don’t recolour well when the GTK colours change.  There are two possible workarounds:
  • Introduce custom properties to scale and colourise the pixmaps as appropriate.  v2 is already capable of pixmap colourisation (it’s used quite heavily in Crux, since that is a pixmap theme, but rarely elsewhere).
  • Use SVG images instead.  This immediately brings up the problem of how to style these images: we could of course use this very CSS to style them, but then our custom callback functions to get GTK colours would still need to be honoured somehow.

Conclusions:

• CSS has possibilities as a window border format: it is a standard and well-understood format and there are plenty of tools around to edit and parse it. However, it is certainly not as powerful as v2 and probably cannot be.  That may not be a problem, as we said before.
• As somebody mentioned earlier, research is needed to discover which features of v2 are commonly used, and therefore necessary in any possible v3.  We need to make a big collection of themes and score each feature with how heavily it is used.
• Box-based layout is simpler for humans to edit (and perhaps to understand in general) than expression-based layout.

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

The menu currently has around a dozen options.  What is the optimum length for this menu?

These are the current contents. Which of these should not be in the menu by default?

• Minimise
• Maximise
• Move
• Resize
• Always on top (checkbox)
• On every workspace / On only this workspace (radio buttons) ★
• Move to workspace above, to the right, below, to the left (four separate options, only the applicable ones being visible) ★
• Move to another workspace (leading to a submenu) ★
• Close

Some say that the workspace options (★) are overkill. They are by far the most complicated options in the menu, and they take up a large amount of space even for people who do use workspaces.  Perhaps that’s not everyone; if workspaces are something that only advanced users are aware of, maybe these options ought to be enabled separately.

There are other things we could put on the window menu, if it doesn’t get too crowded.  What extra options would you like to see there?

• Take a screenshot of this window
• Share this window with another user using VNC
• Screencast this window and upload it somewhere using Istanbul
• Anything you can bind a keystroke to.  (Nargery: This would be kept as a hint on the root window, encoded either as a keybinding name (e.g. “toggle_shaded“) or as a representation of an EWMH command.)
• Similarly, application-specific options, given in a hint on the window itself: so your music player could have play, pause, and so on when you clicked its entry in the task switcher; consider how this could move towards replacing permanent notification applets, evolving into being part of notifisation in Metacity 2, and how useful it might be in gnome-shell.
• By analogy with right-clicking on the desktop allowing you to set the wallpaper, perhaps “Edit window borders“, which would take you to a dialogue which let you reorder the buttons, modify which user-chosen options were in the window menu, pick a window border theme, and perhaps even do some light theme editing.
• …your ideas here…

Photo © Beautiful Rust, cc-by-nc-nd.

This seems entirely reasonable.

Photo © Janet McKnight, cc-by.

There are two ways this can be done.  The simplest way is to use a hint whose name begins _METACITY; this doesn’t require us to talk to anyone.  It’s sometimes one way of starting the process of adding a feature like this.  Of course, it means that the feature’s unlikely ever to work with any other window manager.

The better and more extensible way is to make a new standard hint, one beginning _NET_WM.  This means adding the hint to the Extended Window Manager Hints standard (the EWMH).  Changing this standard means arguing it out on the wm-spec list.  The maintainers would like not to be the only ones to raise new ideas on this list.

In either case, the toolkits (such as GTK) will then need to be updated to mark the relevant windows with the relevant hints, and finally the applications will probably need to be updated to use the new functionality in the toolkits.  You can see, gentle reader, that enhancements like these are the source of more work than the average enhancement.  They may nevertheless be worth the effort.

This entry exists mainly so that we can link to it when the issue comes up.

Photo © !!sahrizvi!! (back in Dubai) !!, cc-by-nc-nd.

This is not unlike the special frame style suggested here for root windows.  However, while there’s already a way for the window manager to tell whether a window belongs to the superuser, there’s currently no way to tell whether a window is a warning, so this would need a change made to the EWMH and then need all the toolkits fixing to use it.  It’s thus rather nontrivial, although it may still be worth it if it helps users.

Because this requires a change to the theme format, it must be committed first on a branch.

I am seriously entertaining the idea of doing away with the window and frame_style_set tags in v3 of the format, and just using tags on frame styles such as maximized, shaded, focused, unfocused, root, warning, modal, and so on, with some well-defined and intuitive rule about how to break ties:

<frame_style geometry="foo" tags="border focused maximized">
<piece position="title">   ...

Photo © Robin Gallagher, cc-by.

This is a reasonable and important request.  It is, however, not at all simple.  Metacity is the program which decides whether to raise the window, and there is currently no way for Metacity to know you’re about to start a drag-and-drop operation.

One rather crappy workaround is to tell it by holding down Super or AltGr.  This works, but it’s not elegant.  The system should be able to know.

This is not what raise_on_click does.  Please forget about raise_on_click.  It won’t solve your problem.

The correct answer is fixing this in the EWMH.  Luboš had an idea about this back in 2004 called _NET_WM_TAKE_ACTIVITY, and Elijah improved on this later with a more complicated idea called _NET_WM_MOUSE_ACTION.  Getting this into Metacity is GNOME bug 152952.  Whatever happens, it’s going to need changes to GTK and to various applications, particularly including Nautilus (the file manager).

Far more of a detailed writeup, including feedback from some of the people involved, is found in this entry. Your chronicler believes that implementing this is worth the fairly considerable effort to fix.

Photo © wili-hybrid, cc-by.

I’ve been considering the idea of making it a property on the root window called, say, _METACITY_SYSTEM_MENU. Let’s think about how this could look. It would need multiple lines, and multiple fields for each line; so let’s say the lines are delimited by newlines and the fields by tabs, for easier processing. The first field in a line would dictate the function of the line. If it began with a star it would be something special, and we only need to define two of these, “*workspacemove” for “move up, down, left, right a workspace” and “*workspacemenu” for the submenu of workspaces.

Let’s say, though, that if it began with a colon it would represent an EWMH message.  A naive approach would be to send these messages when they were chosen; a more efficient approach would be to fake one up and pretend it had been received, to avoid the round trip to the X server. NARGERY: Let’s say that it consists of a number of subfields separated by colons; the first is the atom for the message_type; the second is “W” if the window field is to be filled in with the ID of the current window, and empty otherwise; the third and following are the contents of data.l[n], with any decimal integer standing for itself, a blank standing for zero, a dot followed by any characters representing an atom, S standing for a source indication and T for the current server time.  Trailing blanks can be omitted.  (For these purposes we pretend that toggling _NET_WM_STATE_HIDDEN minimises and un-minimises.)

Alternatively we could simplify matters by using a percentage sign followed by one of the names of the keybinding actions, such as %close.  This would be simpler but less portable to other window managers, if this ever became some kind of a standard.

The remainingfields for an action would be the string which represented it in the current locale and possibly a string representing the keybinding, in case we didn’t want to work it out for ourselves.

Given all this, we’d avoid duplicating the menu in both programs, and more importantly we’d make it possible to add entries to the menu, as requested in GNOME bug 345233 and elsewhere.  It has been suggested, for example, that if you have a program installed that allows you to share windows across the network, every window should give you the option of doing so in the system menu.  That could quite easily be done using “%run_command_n” here.

(Written during a long compile, so apologies if it rambles.  Also bear in mind that squibs of the day are supposed to be blue-sky ideas!)

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

Photo copyright Zarko Drincic, cc-by-nd.

• for G in $(locate metacity-theme-1|grep /usr/share/themes|cut -d/ -f5); do metacity-theme-viewer $G; done

Mean client-side times on my system to draw each frame, in ascending order of speed:

• Prelude (the theme given in the previous post): 1.3ms
• Bright: 1.9ms
• Atlanta: 2.0ms
• Mist: 2.1ms
• AgingGorilla: 2.2ms
• Metabox: 2.2ms
• Simple: 2.3ms
• Esco: 2.4ms
• Glider: 3.7ms
• Crux: 3.8ms
• DarkRoom: 3.9ms
• ClearlooksClassic: 4.3ms
• Glossy: 4.5ms
• Clearlooks: 4.6ms
• Inverted: 4.6ms
• Human: 6.0ms