February 2009 – …for the adult in you

meta_warning() and dialogue boxes

meta_warning example I didn’t expect to get useful suggestions from the Linux Haters’ blogs, but here’s something that might fly: they point out that warnings from the window manager end up in .xsession-errors where nobody ever sees them. But now that we’re using Zenity for dialogues throughout, there’s no reason why we can’t adapt meta_warning() to put up a dialogue every time a warning is issued, which might alert users to useful things, such as why they can’t bind the keystroke they want. Having a way to turn this off might also be helpful.

Quick mention: a theme editor

Someone is working on a Metacity theme editor called Metacity Themer. It appears to take rather a different approach from Opacity; it’ll be interesting to see how this turns out. I’m not sure whether I should abandon Opacity; I wasn’t working on it anyway much (though I had thought about it quite a bit) and I don’t really have time to finish a theme editor anyway with the amount of work that Metacity needs, so Opacity would have been a while off prime time anyway. Let us know what you think of Metacity Themer.

Zenity, sessions, and window matching

It has been pointed out that session management in Metacity is currently a bit broken. Firstly, it leaves a lot of useless files around. I assume that the only session file which is really necessary is the most recent one. Secondly, I recently found and fixed a bug where Metacity actually crashed when attempting to save a session. I wonder nobody had found it before, but maybe this shows that session management doesn’t get used, or at least looked at, very much. Thirdly, there’s still a bug in the session management that I found the other day while fixing Zenity support, wherein it tries to put up a dialogue before closing the session… and then always quits, so you can’t see what you were told.

It seems to me that session management is three-quarters of window matching, but isn’t half as useful. It further seems to me that if window positions were remembered properly during day-to-day use, they would be remembered properly across sessions. This seems to be a rather compelling argument for dropping session handling entirely and adding some kind of window matching in its place. After all, it wouldn’t affect our claim to be a lightweight window manager to drop one broken feature and add a more useful one instead.

Photo © TheBusyBrain, cc-by.

Away

I’m away on business until the middle of next week, so posting here will be scarce.

Squib of the day: keep the menu in one place

At present the system menu, which you see when you right-click anywhere on the titlebar, left-click the menu button, or right-click an entry on the pager, is hard-coded separately into Metacity and libwnck, and required to be the same in both places.

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.

Squib of the day: don’t manage all screens

In GNOME bug 351647 the suggestion is raised that there should be a setting to prevent Metacity from managing certain screens. At present, Metacity manages all screens on its display. Thomas provided a patch which allowed “--ignore-screens=1,3” to be passed on the command line. The reporter would prefer a GConf key.

I think which is better depends on the use case. Is it more likely that people will always want Metacity not to manage screen 1, say, because they want to leave it uncomposited? Or is it the sort of thing they’ll start Metacity for ad hoc, and so will want to specify it on the command line?

Photo © Cindy Seigle, cc-by-nc-sa.

another crazy idea

Almost everything we bind keys to could be done with an external application via EWMH, and on my computer there’s no perceptible speed penalty. (I’m sure there is on slower machines.) Perhaps there should be a configure switch not to include the code to do everything except the things which pop up switchers (and another switch not to include those, in case you use superswitcher) and then we could supply a separate executable for people who’d turned them off, so that pressing the “move to workspace right” key actually did “metacity-move –right” or something. Maybe it would reduce the memory footprint on faster machines. Maybe on the other hand it wouldn’t be worth the trouble.

Photo © Telstar Logistics, cc-by-nc.

Squib of the day: walk through workspaces

I don’t know why switching continues to be a source of squibs, but there it is. In GNOME bug 570817 someone is suggesting a way to walk through workspaces (presumably only populated ones, but that’s not clear) in the same way that hitting and immediately releasing alt-tab moves you to the next window without regard to where it is.

Of course again we could solve this simply with an external script, and I’m wondering whether there should be a Bugzilla status for RESOLVED CANFIXWITHASCRIPT.

More seriously, perhaps there should be a collection of these scripts and a master script which listed them all in a dialogue box and modified the user’s GConf settings according to which ones were turned on. (I wonder whether the control-center people would object to having this in an “Advanced” button somewhere, or whether that’s too bells-and-whistly.)

Update: Since the script was so simple, I spent twenty minutes writing it and closed the bug. I think this demonstrates that we need a Perl module called X11::Protocol::Extended which knows about the EWMH, so these scripts are even easier to write. Maybe I’ll write it.

More on themes, and on why Human’s slow

Four points of note in theming today. Your thoughts on these, gentle reader, are appreciated.

Screwtape has been working on a Metacity theme to look like Mac OS Classic. The resulting list of tips and tricks for writing Metacity themes ought to be required reading for all themers. Screwtape, would you mind if we linked to it from the sidebar of this blog?
I have added a small amount of optimisation to line drawing: if a line is horizontal or vertical, the second x or y coordinate is not stored, and if a line’s beginning and ending coordinates are identical, neither the second x nor the second y coordinate are stored, and the line is drawn as a point. This seems to have sped things up a little. (Note, by the way, that speeding up Metacity themes will also help Compiz along too.)
As a followup to my previous post about Human, I have checked to see what part of drawing the gradient is so slow. The results are clear: preparing the bitmap is fast, and painting it is slow. Almost the whole wait is taken up with the call to gdk_draw_pixbuf(). The docs contain a stern warning:

On older X servers, rendering pixbufs with an alpha channel involves round trips to the X server, and may be somewhat slow.

Since all the gradients have an alpha channel, I am led to wonder whether the delay is caused by this problem, and what possible workarounds there might be. (Update: But removing the alpha channel doesn’t make much of a difference, so maybe it’s just that painting this large an area is inherently slow. I wonder whether we can create a 1xn pixel tile instead and tile it along the length of the area, and whether that would be faster.)
The RPN version of the expression parser is rather faster than the existing parser, and (I believe) simpler to understand, but expression parsing is not a major timesink at present anyway, so it saves at most a few hundred microseconds per frame draw. I am wondering whether merging it is worth the chance that it might misinterpret some theme somewhere. Perhaps now immediately after a branch is the best time to consider it, though.

So, why is Human slow?

I mentioned a while back that Human is the slowest of all common themes, taking 6ms to draw the average frame. It occurred to me to wonder why this might be, of course, so I took the opportunity to instrument it. Here are the results. The height of the diagram spans six milliseconds. You will note firstly that the theme carries out a large number of very simple operations like lines and rectangles, which are very fast, and next that there are four long pauses which I have numbered in red:

Drawing a gradient. This is the first gradient in title_background, covering the entire width of the titlebar and half its height. There are three other gradient operations, and none of them take that long; this could be some caching mechanism in GDK but is more likely to be because at least one of them is only a single pixel high. The other two are a bit of a mystery; the output says they should be part of piece 11, bottom_edge, but that isn’t used in Human.
Drawing a tint. Again, it’s the first one in corners_hilight_shaded, so maybe some caching effect, but this is also the only tint which is 1×2 pixels high instead of just 1×1; there is one tint which is 2×1, and this is visible taking longer slightly below the number 2.
Drawing the title text. This happens four times, and two are very fast and one is very slow. I can’t account for this.
Drawing the title text again; see above.

I think this shows that gradients and tints need to be faster.

(Update follows >>>)