Uncategorized – …for the adult in you

Squib of the day: named colours

GNOME bug 121866 would like a way to set drawing colours according to palette entries in bitmap images in the same theme, as well as giving literal RGB values or giving a reference to a GTK colour. It is suggested by the reporter that this could be done with the XPM format, which allows colours– or rather, entries in the palette– to be named instead of specified: foreground, for example.

This is quite a vague requirement. Because this requires a change to the theme format, it must be committed first on a branch. However, using bitmaps in themes at all is somewhat deprecated.

A useful variation on this idea would be to allow a set of colours to be undefined within a theme, which could be done by extending v2’s support for colour constants, and then allowing other sub-themes to specify only the missing colours. Or perhaps the user could choose the colours for themselves as parameters to the theme; this part we could even do already with no change to the theme format, by adding a new GConf key which allowed redefinition of colour constants in the current theme. You can imagine a standard utility which would read the theme file and give the user colour pickers for each constant, then set the values in GConf.

This would then bring us back to the original problem and might require us to be able to change a specific colour in bitmaps as appropriate; alternatively, we could just say it was one more reason why bitmaps in themes are a bad idea.

Photo © Bernat Casero, cc-by-nc-nd.

Squib of the day: Restore z-order

In GNOME bug 85793, someone points out that when a session is restored, the windows are restored out of order. (The z-order is the depth of the window in the stack on the screen, so called by analogy with Cartesian X and Y coordinates.) So if a window was on top when you logged out, it might be on the bottom when you logged back in.

Session restoration is currently broken anyway, but whether we fix that by making sessions work again or by implementing window matching, we need to make sure that z-order is restored correctly.

Photo © Leo Reynolds, cc-by-nc-sa. Mashup of previous Flickr work. Isn’t free content wonderful?

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.

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

Photo © just.Luc, cc-by-nc-sa.

metacity 2.25.34

Matt Kraai noticed a stupid mistake in last night’s release, so this is a brown paper bag fix. It was too late at night to write anything sensible, clearly.

What is it ?

Metacity is a simple compositing window manager that integrates nicely
with GNOME 2.

What’s changed ?

Fixes to Thomas’s earlier fixes (Matt) (GNOME bug 562939)

Translations:

None

Where can I get it ?

2-25-5 released

What is it ?
Metacity is a simple compositing window manager that integrates nicely
with GNOME 2.

What’s changed ?
Thanks to Thomas Thurman for improvements in this version.

Allow third-party apps to decide whether a window appears on all workspaces (Thomas) (GNOME bug 557536)
Fixed keybindings script (again) (Thomas)

Translations
David Planella (ca), Robert Millan (ca@valencia)

Where can I get it ?

bad30bc7a0e935a1dd0ed31f863dd05f metacity-2.25.5.tar.bz2
9ff4b32d3255ad477ae1f1273b8e0abb metacity-2.25.5.tar.gz

Logging again

As I mentioned earlier, Metacity has quite a good logging system, but it’s almost never turned on; you have to set some environment variables. If someone reports a bug, we have to ask them specifically to turn it on, and then run Metacity again, and see whether the problem recurs. Federico and Luke suggested earlier that it could be supplanted by a gconf key, which users find easier to turn on and off than an environment variable; I think that’s a generally good idea.

I’m also floating the idea here of encouraging people to log all the time, at least on unstable builds, perhaps by making it the default. In that way, when something went wrong there’d be a logfile to refer to, even when you couldn’t recreate the bug. Obviously you’d be able to turn it off as well.

The files would be dated as Sabayon now can. Since we also have the ability (for session management) to dump a list of window details, it might be useful to dump them in the file when it got closed, too. Perhaps we could do some kind of logrotate thing so that the files didn’t grow like that fish (no, not our own Wanda).

Federico mentions that bug-buddy now has the ability to attach logfiles to bug reports; I think this would be enormously useful, and save us days of debugging time, but is still a bad idea because nobody wants a list of all the names and movements of all their windows for the past few hours attached to a public bug (some people may remember the unfortunate side-effects last year of having a stack trace of someone’s totem process attached in such a way). This is an existing problem, since it’s inherent to the use of logfiles in a window manager, and applies whether the log is supplied by bug-buddy or attached by a human. I’m having trouble thinking of a good way around it.

A decent set of regression tests that gets run every night. (This is under development.)
Documentation of every function and struct.
No outstanding bugs in the bug queue; everything needs to be resolved (maybe wontfix), be being worked on, be scheduled to have work done on it, or have a reason we’re not working on it right now.

Category: Uncategorized