Squib of the day: Where did I come from?

Down the Fretboard.Two rather similar squibs today.

GNOME bug 96348 calls for an animation to be shown when restoring (unminimising) a window, as we already do when minimising. I can’t see any problem with this idea.

GNOME bug 97288, however, would like all new windows to have the opportunity to come from somewhere.  If you open a document from the file manager, for example, the window should appear to zoom out of the icon.  Presumably this would involve modifying the startup notification protocol to pass in a pair of (x, y) coordinates.  This would need some changes to nautilus and friends as well as to Metacity, so it seems non-trivial.

However, even if these coordinates were missing, we still know the ID of the window which launched the new window, so we could assume it came from the centre of its launcher.  Something similar could also be done with transient windows.

Photo © lant-70, cc-by-nc-nd.

Squib of the day: Macro cleanup

Abandoned MachineryIn GNOME bug 94111, Havoc points out that some of the macros we use for checking certain features of windows are incorrect.  Fields with names like has_foo_func denote whether the window gives us permission to foo it.  Macros with names like ALLOWS_foo take these into consideration and also whether the operation is possible right now (for example, you can maximise a window only if it allows maximisation in general, and also if it’s not currently maximised).

The bug requires checking these macros have correct names, and making sure they do what they’re intended to do.

This whole business does make me wonder why we’re using macros for this sort of thing, anyway.  Given a modern compiler, do macros win us anything that inline functions don’t, besides extra difficulty in debugging and readability?

Photo © Thristian, cc-by-sa.

Squib of the day: Workspaces should switch instantaneously, or not

When GNOME bug 86590 was born, it was a request to make workspaces switch instantaneously when you panned around them using the workspace switcher with ctrl+alt+arrow.

Then that was fixed, and someone else complained that it was too slow, and inconsistent with the alt+tab popup, which doesn’t switch until you let go of alt.  They asked for it to be reverted.  Someone else suggested a compromise: if the user pauses while moving through workspaces, flip to that workspace without removing the pager.

Of course, then we’d have to consider whether we should do that with alt+tab, too.  It’s possible that the two cases are different enough that there’s no good analogy here, though:  workspaces can be named, for example.  It’s possible as well that they’d become different enough for there to be no good analogy here if we had thumbnails of the workspaces instead of the icon-based boxes we have now.

So the options now are:

  1. Switch when they let go of the keys, as we used to.
  2. Switch after a delay, as suggested above.
  3. Maybe it’s fast enough these days and nobody cares any more.
  4. We could keep all the windows on all the workspaces mapped all the time, like Compiz does, which would make things a lot faster anyway, and would reduce to the previous case.

Photo © Matsatsinis Fragiskos, cc-by-nc-nd.

Squib of the day: line weight

Empty Victoria Line Tube TrainAt 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: Drag and drop should work properly

DragonIn 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

365 3/26: Going on a Key West adventure/bike rideGNOME bug 97725 raises the interesting idea of associating keys with windows.  Two differing approaches have been advocated:

  1. Have a set of keys which work to “bookmark” windows, and a corresponding set of keys which mean “jump to bookmark n“.
  2. 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

Ladybird in crocusRather 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.

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

HarboursideThis 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

&quot;Super Cloud&quot;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.

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.