Bugs and issues – Page 5 – …for the adult in you

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.

Photo © Thristian, cc-by-sa.

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.

Photo © frohner-1, cc-by.

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?

Photo © Bruno Peck, cc-by-nc-sa.

Squib of the Day: Ctrl+Alt+Delete

GNOME bug 130632 raises the idea of being able to put up the GNOME system monitor with a keystroke bound by default to Ctrl+Alt+Delete, as on Windows, so that users can kill applications and so on. The usability people say this is fine as long as the system monitor gains a prominent logout button. This has been raised against the system monitor as GNOME bug 143235. Perhaps, gentle reader, we should add the keystroke anyway and not wait indefinitely for the system monitor maintainers to add the button.

Update: GNOME bug 99335 is also asking for a keybinding to log out, and someone has suggested Ctrl+Alt+Delete. Perhaps the two could be fixed at a stroke.

Update: GNOME bug 131617 is asking for a keybinding to xkill or its equivalent in the panel, which could also be fixed by having a keybinding like the one discussed above.

Photo © Gone-Walkabout, cc-by-nd.

Squib of the day: “(as root)”

GNOME bug 549389, which has a couple of duplicates, says that if a window is owned by an app which is running as a user other than the user who’s running Metacity, then it should have “(as fred)” on the titlebars, just as it would have “(on chiark)” or whatever if you were running the app remotely. The obvious very useful case here is to have “(as root)” when you’re running a program as root, to remind you to be careful.

The code to do this exists in Bugzilla now, so we can check it into trunk at any point.

Other suggestions, some better than others, have included:

Use an alternative theme for root windows
Draw a red border around the window
Use a label (a space as big as the titlebar immediately below it) saying “Root process”
Say “(as superuser)” instead of “(as root)” in case users don’t know what “root” means
Have a hint not to write the username in the titlebar so that apps which generally run as root, like the package manager, don’t have baffling information all over their titlebar.

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.

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

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?