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

Squib of the day: line weight

At present all lines are drawn at the same thickness. However, some people such as partially-sighted users require particularly thick lines. GNOME bug 86040 suggests that the line format be extended to give the width as a fraction of the current icon height.

Since this is a change to the format, it must appear first on a branch. This bug actually predates v2, but wasn’t included in that version because it wasn’t marked as blocking the v2 tracker bug.

If this would still be useful to anyone, it could certainly still go into v3 of the theme format.

This bug is perhaps the first place where the use of SVG was suggested as a workaround for having to add new features. Elsewhere, someone also suggests a novel idea of allowing themes to ship TrueType fonts which contain unusual glyphs, in order to have access to another well-defined vector graphics language. Of course, this would be subsumed if we decided to use SVG.

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

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?

Squib of the day: Drag and drop should work properly

In GNOME bug 80984 (closely related to GNOME bug 76672), someone is asking for the window manager to help out with drag-and-drop. The problem is that a drag-and-drop operation should not raise the window it begins in, because raising that window could obscure the window you’re planning to drop the object into.

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.

Squib of the day: keys for windows

GNOME bug 97725 raises the interesting idea of associating keys with windows. Two differing approaches have been advocated:

Have a set of keys which work to “bookmark” windows, and a corresponding set of keys which mean “jump to bookmark n“.
Have a keystroke which means “bookmark this window using the key I’m about to press”, and allow users to press bookmark keystrokes in the alt+tab window.

It is of course important that the bookmarks are associated with a given window indefinitely, otherwise they become a lot less useful.

As a step towards the second option, I’ve written a very quick and hacky script called metacity-bookmark. The name is a little misleading, because it should work with any EWMH window manager; it uses the window matching technique described in this post. As usual, you’ll need X11::Protocol installed from CPAN (“sudo cpan X11::Protocol“).

Bind the program to some key or other, which we’ll call Bookmark from now on, and then you can do:

Bookmark + key — jump to the window identified by key
Bookmark + Space + key — identify the current window by key

Feel free to play with this and let me know what you think. I’ve made little windows pop up to tell you the program was running, inspired by the “Compose” indicator that used to appear onscreen on old DECs, if my memory serves.

One obvious limitation of the current script is that when it activates a window, it doesn’t switch to the workspace which the window’s on. I may fix this another day when I fix all the other problems with this script, but if you fancy diving in and fixing it yourself, it shouldn’t be too hard.

As a possible extension to this, windows could also have bookmarks automatically associated with them from their creation, based on their name– for example, the first GIMP window could automatically be given “G”. And either kind of bookmark could be displayed in the Alt+Tab switcher next to the associated window’s preview or icon.

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

Squibs roundup, number 1

Rather than allow squibs to disappear into the bit bucket, we’ll post the status of all the squibs so far every so often (except any that were already fixed or rejected at the time of the previous roundup). There is only limited time to fix things, so the burden of proof is on explaining why things should go in. Anything which says “no action yet” will appear on the next squibs roundup.

live previews — no action yet; no consensus reached even on whether previews per se are a good thing
Exposé-alike — rejected, can be done in a script (but nobody’s written the script; any volunteers?)
speed up alt+tab — no action yet
move in a direction — fixed with a script
prefixes — rejected, considered silly and could be done with a script anyway
sound effects — fixed
remove alt+tab — rejected because of implications for heavy system load
extend plugin possibilities — no action yet, but more a thought experiment than a proper squib
walk through workspaces — fixed with a script
don’t manage all screens — pending; patch available; needs converting to GConf. Any volunteers?
menu in one place was more a thought experiment than a proper squib.
“as root” — fixed.
ctrl+alt+delete — no action yet; will probably put it in as a binding for the system monitor for the moment, since that’s very simple, and perhaps come back to it later
show size during resizing — no action yet; this may count as what Havoc calls crack, and I’m thinking about rejecting it
naked modifiers — no action yet; recent and still being discussed; will reappear on the next roundup.
binding mouse buttons — no action yet; patch available; still being tested.

Feel free to keep advocating solutions (or providing patches) in any of the comments sections or the bugs that the posts point to.

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

Binding mouse buttons

This was going to be the squib of the day for May 8th (yes, I have it all planned out) but I thought it was so interesting and potentially useful that I wrote a patch already.

Metacity lets you bind keystrokes to all sorts of things, but it doesn’t let you bind all those extra buttons on your mouse to anything at all. I don’t have a particularly flashy mouse, and it has the usual left and right buttons, plus a scroll wheel (i.e. up and down buttons) which doubles as a middle button, and can be pushed left and right as well, plus two shoulder buttons and a two-way zoom control. That’s eleven buttons. GNOME bug 374601 asks for them to be bindable in the same way keystrokes are bindable.

The patch added this evening lets you bind these as Buttonn, e.g. Button5, possibly including some modifiers such as <Alt>. Which button Button5 is is unfortunately down to you to find out; you can discover the answer using

xev|grep -A2 ButtonPress

and clicking in the resulting window with each button in turn.

Feedback on the patch is very welcome; I’m not certain the use of a flag bit rather than a separate flag was wise, and I don’t know whether it was worthwhile to forbid the user to bind the left, middle, and right buttons and the scrollwheel on the grounds that they’re commonly used by applications. I mean, perhaps you want <Alt>Middle to do something and you don’t really care that it’s taking a possible button press away from your apps.

Try the patch out and see whether it works for you. I’m trying it myself at the moment with the various extra buttons bound to switch_to_workspace_n and it’s proving its worth already.

Squib of the day: allow binding naked modifiers

GNOME bug 150897 points out that as things stand you can’t bind naked modifiers to actions– for example, you can’t have it so that pressing alt on its own takes a screenshot.

The reason this might be useful is that pressing super (which is generally the key with the Windows logo on it) on its own brings up the main menu in Windows, and it would be nice to allow it to do so in GNOME as well.

Of course it could also be done by making the key not be a modifier, but then you would lose the ability to make super-M or whatever do something.

Your chronicler can foresee having to switch away from their trusty IBM Model M to test this one.

Squib of the Day: Show size during resizing

GNOME bug 130821 suggests that all windows should have the current dimensions shown in the middle while they’re being resized. Everyone seems to agree this is a good idea, and I’m not sure why we haven’t just committed it yet. Any naysayers?

Administrivia

LiveJournal users may read the Metacity blog by friending its syndicated feed.
Photographers and other artists who publish work under the Creative Commons licences and who would like their work to appear occasionally in the “bug of the day” series here should contact Thomas by email (tthurman at gnome dot org). These would be interleaved with random beautiful things we find on Flickr, as usual.
Remember when there was a talking version of the blog (the little Listen to this links on every post)? Was that useful to anyone? Would anyone want it to appear on iTunes?

Policy about theme versions

Metacity has a policy about enhancements which require changes to the theme format. Metacity has to be both backwards and forward compatible. In other words, it’s not enough that a later version of Metacity can run with themes intended for an earlier version. Earlier versions must also be able to run with themes intended for a later version.

In order to accomplish this goal, themes are kept in a file named metacity-theme-n.xml, where n is the number of the version of the theme format. A theme which supports a version should also have files for all the preceding versions, and Metacity will read only the highest version found which it can understand and leave the rest alone.

This works. However, if there were hundreds of theme versions, it would become unwieldy. So we save up enhancements and commit a bunch of them all together. The only time this has happened so far was in October 2006, when v2 was introduced. (Not many people are using v2, even over three years later, and even though users evidently want the features it brings. This may be because theme artists aren’t sure how to create them. One of the advantages of a theme editor would be that it would be able to take care of creating valid intermediate versions for you.)

Some enhancements still being suggested will involve changes to the theme format. For example, Screwtape has suggested a special window state representing windows which are running as root, so that they can be drawn using a different colour or something. Enhancements such as these will all have to be made on a branch and merged all together at some time in the medium future, perhaps next year. I have made a category to group posts about such enhancement requests into.

One of the big questions about v3 is whether it should be SVG-based– the so-called Vectacity format. This will quite possibly win us very little for the extra effort that will be required to mould SVG into a format which can adequately represent window decorations, so Vectacity may not happen in version 3, or at all.