another crazy idea

Tomy Switch Switch controlsAlmost 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

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

You can switch in a direction!

BridgeWhen I posted yesterday’s squib, I really didn’t expect six people to say they’d use it. Someone plaintively left a message on the bug saying “Please make it possible for devilspie to add this feature!” Well, it is possible for devilspie or any other addon to add this feature, and for that reason it’s not a big difficulty to write it as an external script.  As an added bonus, it should work with Compiz or KWin or any other EWMH-aware window manager.

To play with the script:

  1. Download the current version from GNOME bug 152661.
  2. Put it in your path as metacity-direction.
  3. Install X11::Protocol by typing:
    sudo cpan X11::Protocol
  4. Open gconf-editor and set /apps/metacity/keybinding_commands/command_n, where n is any set of four unused values, to:
    metacity-direction e
    metacity-direction s
    metacity-direction w
    metacity-direction n
  5. Set /apps/metacity/global_keybindings/run_command_n to an appropriate set of values, like “<Shift><Alt>Right”, etc.
  6. Enjoy.

The algorithm is supposed to be the same as fvwm’s, but if you have suggestions for tweaking it, let me know.  The program should also demonstrate how to do fun EWMH things from Perl.

Photo (c) Katie Sutton, cc-by-nc-sa.

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.

Squib of the day: speed up alt-tab under compositing

Light Switch Complicator GNOME bug 504729 suggests that switching with alt-tab, while using compositing, is too slow. This is because all the images of the windows are scaled on the client side before the window is displayed.

There are two possible answers to this problem.

Firstly, we can check for key release while scaling is happening, and if one is received, abort scaling and simply switch to the next application.

Secondly, scaling can be faster if it’s done server-side.  This is possible but apparently there’s a common bug that it hits.  Fixing this would also mean that we got to have animated previews easily.

I think the first solution should be added in any case, and the second should be added when it’s possible.  I can add the first solution; I’m not sure I know enough to fix the second.

Photo © L. Marie, cc-by.

Exposé, part two

Light Strikes #  104Quick on the heels of our previous post on this matter, and Iain’s explanation of how it can be done in an external process and spawned on a keypress, malept points out Skippy, a program to do just that.  However, it appears to be unmaintained.  Does anyone fancy picking up the reins?  Possibly there should be some Metacity-specific tweaks, like being able to un-Skippy by pressing the same key you used to launch it.

I think the existence of Skippy is good enough reason to close the bug.  If anyone wants an Exposé-like effect, they should be able to install Skippy and tell Metacity about it without much effort.  Perhaps some distros might even ship them together.  If we had an FAQ, this should go in the FAQ.  Maybe I’ll write an FAQ.

(Yes, the same principle can in theory be used to get the rotating cube effect.  No, I don’t want to write it.  But since it can be an external program, there’s absolutely nothing stopping someone else writing it and then I’ll post about it here!)

Photo © Taylor James, cc-by-nc-nd.

Squib of the day: Exposé

ExposeIn GNOME bug 502491 someone is asking for an effect like Exposé on OS X.  Iain, who wrote the compositor and ought to know, believes it would be better done as a separate program.  There was an attempt to do this a while back, called Expocity, but nothing much came of it.  Does this mean the bug is INVALID?  Should the external program exist?  Anyone fancy doing it?

Includes the memorable exchange:
“Every time I propose an enhancement, you say ‘go for it’.  What are you doing?”
“I’m cooking my dinner.  What are you doing?”

If it was a separate program, it could be activated by a mouse button or a keybinding in the same way that, say, Print Screen is currently activated.  The program could move windows about using the EWMH, but I don’t see how an external utility could tell the compositor to scale the contents of windows down and back again.  Iain, can you throw me a clue? Update: Thanks.

Someone said yesterday in the discussion on animated previews in the alt-tab switcher that an Exposé-like effect would be good for everything that animated previews would, and more.

Photo © Underpuppy, cc-by-nd-sa.

Squib of the day: Live previews in alt-tab

True to my promise, here’s the first bug/squib of the day.

In GNOME bug 567757 someone is asking for live previews in the alt-tab window.  I can’t think why this would actually be useful, as opposed to pretty, and it sounds like a lot of work and a source of new bugs.  I am therefore minded to say no.  Can anyone think of why it might be worth the trouble?

Know all men by these presents…

sheep  &amp;  her lambI tried to discuss the gtk_window_present() problem earlier, but I only managed to confuse myself. So here’s an extra rundown; perhaps we can move towards solving it.

The problem is that there’s a call, gtk_window_present(), which is very vaguely specified:

Presents a window to the user. This may mean raising the window in the stacking order, deiconifying it, moving it to the current desktop, and/or giving it the keyboard focus, possibly dependent on the user’s platform, window manager, and preferences.

There are at least four ways of dealing with this request.  I hope I can establish a consistent terminology for them here.  Suppose we are looking at workspace 1, and an application attempts to gtk_window_present() an existing window on workspace 2.  We can:

  • Summon: the window is moved to workspace 1, so now we’re looking at it.
  • Visit: the window stays still, but we move to workspace 2, so we’re looking at it.
  • Pulse: the window stays still, we stay on workspace 1, but we set “needs attention” so it pulses on the taskbar.
  • Nothing: we do nothing.  This is allowable, but I think we can discount it.

gtk_window_present() is implemented using _NET_ACTIVE_WINDOW, which according to its specification allows the WM to make the requested window active (which could mean either Summon or Visit), or Pulse, or Nothing.

Many applications use gtk_window_present(), and because of the vagueness of the spec, there’s no agreement on what they mean by it.  Three instances which have been identified are:

  • Firefox. If you click a link in your email program, it will summon your current browser.  If this is Firefox, and it’s appearing in a new tab, it will gtk_window_present().
  • Pidgin. If someone talks to you, it will gtk_window_present() the chat window.
  • Nautilus. If you use one window per directory, and you request a directory that is already open in another workspace, it will gtk_window_present() the window for that directory.

The disagreement extends even to what Metacity should do when asked to present windows in each of the cases above.  Here are some opinions; feel free to add your own in comments, or tell me where other people have asked for something, and I’ll update this:

  • Firefox: Kevin Downey says we want Pulse.
  • Pidgin: technicull says we want Summon. The devs themselves say they don’t care as long as it’s not Nothing.
  • Nautilus: I think we want Summon here.  David agrees.

Some things which Metacity should not do:

  • Decide which to do based on the application.  This is window matching, and thus a recipe for pain.
  • Add a switch somewhere.  As Havoc said, this boils down to asking “Do you want to break Firefox, or Pidgin?”  And many people (including me) run both.

When people complain about Metacity’s behaviour in this matter, it’s hard to tell whether they’re complaining about upstream or downstream Metacity.  Upstream Metacity does Summon in all cases.  Ubuntu has patched to do Pulse (except for dialogues, which do Summon), as has Fedora, and I believe SuSE has too.  As policy, we usually reconsider policy when several major distributions make the same change, and this means we should probably stop to consider what to do here.

It might be possible for the app itself to hint in the EWMH message which behaviour it wants, if it doesn’t want the default.  Patryk Zawadzki says that the behaviour should depend on the user’s action; if the user carried out some positive action to cause the gtk_window_present() (as in the Firefox case), it should result in Visit, but if it happened through some external event (as in the Pidgin case), it should always result in Pulse. Mathias Hasselmann concurs.  I think this seems a reasonable plan, but the distinction between events generated by the user and not is one which the app is best placed to make, and so we probably also need a hint here.  I’m happy to add hinting as a test; however, the default option will necessarily be “don’t care”, and therefore we will still have to choose a best option as default.

I think most applications may be happy with a default of Summon, and that a default of Pulse is at least better than Visit in most cases, but I’m entirely willing to be convinced otherwise.

What do you think?

Photo © jan glas, cc-by-nc-nd.