Squib of the Day: Ctrl+Alt+Delete

CTRL+ALT+DEL Boat 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.

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

Gentle TouchIn 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.

Squib of the day: walk through workspaces

LightswitchI 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.

Photo © Heated Ground Photography, cc-by-nd.

Squib of the day: extend plugin possibilities

For once, this isn’t about an existing bug– well, there’s a tenuous connection to GNOME bug 311428.

Several of the recent squibs have resulted in the observation that an external script could be made to do the work.  This is true for responding to keypresses, but for problems such as performing some action whenever a window opens it gets a bit harder– the external script must run all the time and either monitor X events or, as devilspie does, get libwnck to monitor X events on its behalf.

It might be a better idea if Metacity (or libwnck) could be given a list of commands to run when windows open, and possibly on other events, to make writing plugins easier.

The (fast!) default would be the empty list, of course.

Another event which it would make sense to be able to tie plugins into is window role change, so that a window-matching script could learn automatically.

It would also be sensible to allow programs to be executed when mouse buttons other than the main three were pressed (so you could launch an Exposé clone by pressing the shoulder button, for example).

Photo © Katie Sutton, cc-by-nc-sa.

Squib of the day: Remove alt-tab entirely

Even super heroes need a day offIn GNOME bug 570079, someone suggests throwing away alt-tab entirely to replace it with an external program, specifically superswitcher.

Of course, you can already do this by disabling the ordinary alt-tab action and then assigning superswitcher to be one of the custom commands, but I think they want it shipped that way by default. I suppose it might be interesting to be able to have alt-tab in a separate process, if you wanted to save memory and your computer was fast enough that it wasn’t too slow to start up.

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

Squib of the day: prefix system for keybindings

Old ad, with Prefixes for phone numbersIn GNOME bug 310842 the suggestion is raised that there should be an option to require all keybindings to be prefixed with a particular keystroke, to minimise the number of keystrokes which can’t be used by applications– there would be only one keystroke, the prefix, that was globally grabbed.  Such a system would be reminiscent of ctrl-A in GNU Screen or ctrl-T in ratpoison.  The default would be to keep things the way they are, of course.

It’s certainly doable, but would this be of use to anyone in the real world?  Do any of you fancy justifying this idea?

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

Squib of the day: move in a direction

ma quando sono gentili le bobbiesIn GNOME bug 152661 someone is asking for the ability to move in a particular direction from a given window (as opposed to from a given workspace).  So you could move to the closest window to the right of the focussed window, for example.  Apparently FVWM has this feature.  (I assume this would be an unbound keybinding by default.)

I really don’t see why this feature would be useful to anyone.  Would anyone care to try to justify its inclusion before I close the bug?

Photo © lavalen, cc-by-sa.