Tools – …for the adult in you

Snap

There has been some discussion on the last post about implementing functionality similar to Microsoft’s “Aero Snap”. Your chronicler has never used Windows 7, but the idea is demonstrated in this video. It appears to mean that:

when a window is dragged to the left or right of the screen, it is vertically maximised, and resized horizontally to half the screen width;
when a window is dragged to the top of the screen, it is maximised;
there are hints elsewhere that dragging to a corner minimises, but this is unconfirmed at present.

There are apparently several people who would like this implemented on the free desktop.

One option is to do it with an external tool. This is the route taken by this tutorial by gotsanity. It’s a simple matter of monitoring the root window for configure events; the link goes to a program which will demonstrate the general principle. Making that program into a daemon which will solve this problem is only a matter of adding code to detect a window crossing screen borders, and some kind of payload for when one does.

The advantages of this approach are:

that it will work with any window manager, and
that we have previously said that almost anything which can be implemented externally should be, to preserve the lightweight nature of Metacity.

The disadvantages, however, are:

the need to keep a separate daemon running; this is a good deal more of a long-term problem than launching one-shot processes on a keystroke,
the difficulty in adding the grey box that tells you you’re about to trigger the effect (though this is certainly not impossible with such a method), and
the change in the moment of triggering from after you release the button to during; this is a side-effect of the modern ability to drag a window itself rather than a wireframe. It would be hard to solve in any way that didn’t feel like a hack. strokinder points out why this is problematic.

The ability could also be implemented within the window manager itself. The advantages and disadvantages of this plan are mirror images of those of the other plan. It may, however, be worth the added complexity. Additionally, the loss of the portability inherent in using an external script may not matter: if this was implemented in Metacity itself, it would presumably be fairly easy to carry it over to Mutter, since in this area the systems differ little. Porting to Compiz may be more of a difficulty.

If anyone with a little programming experience would like to volunteer to work on this, abundant help can be provided; otherwise we will see about dealing with it when the bug queue is reduced a little. Please follow GNOME bug 607694, where this issue is being discussed.

Photo © Darwin Bell, cc-by.

Expansion and external tools

In GNOME bug 517722, a new keybinding is suggested which will make the focussed window take up as much space as possible without covering any other window. If applied to all windows, it would make Metacity behave like a tiling window manager.

The main problem with this idea is the same one we were discussing almost a year ago: the same action can fairly easily be done using an external script and the EWMH. So on the face of it there doesn’t seem to be much reason to add it into the window manager as well.

Of course, this could also be said of several of the less-used bindings, such as “move to southwest corner”. Indeed, some have called for major keybindings such as alt-Tab to work this way. The problem here is that external scripts are slow to start when the computer is overloaded: it’s important that alt-Tab keeps working even when the system load is high. The same thing can’t be said of “move to southwest corner”, though.

Window managers which incorporate a programming language don’t have this issue, since a keybinding can be easily written to reconfigure a window in any way the user pleases, assuming the user is a programmer. But Metacity aspires to be a lightweight window manager, and so does not provide this.

Both of these are reasons why your chronicler is not minded to accept this patch. Perhaps both of these are arguments for moving keybindings such as “move to southwest corner” out to an external script as well, although we could say they are grandfathered. Perhaps also there should be a general policy against anything that can be done in an EWMH script being accepted into Metacity in future.

The number of external EWMH scripts to do this kind of thing continues to rise. Mikkel Kamstrup Erlandsen has been working on putting a number of them together, including one to expand windows, and calling it WinWrangler.

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

Window managers and D-Bus

D-Bus is the standard way for applications to communicate with one another. But the EWMH, supplemented for our purposes by libwnck, is the standard way for applications to communicate with the window manager. GNOME bug 531512 raises the suggestion that even window manager communication should be done over D-Bus, or at least that D-Bus should be an alternative to the EWMH.

There are two main questions to answer before we make any decision here:

Does this buy us anything? Are there people whose lives will be made easier if they can do what they want over D-Bus, without having to include X libraries to use the EWMH? Is this enough to justify the additional complexity in each window manager?
Can we keep this standard? EWMH works with almost all window managers. Switching to a D-Bus-based system brings the risk of fragmentation.

A third option: We could have a separate application which provided a D-Bus service that knows how to send and receive EWMH messages. Such an application could be run in conjunction with any EWMH-compliant window manager. Here’s a quick proof-of-concept your chronicler threw together in a few hours in Perl; let us know, gentle reader, whether you believe it’s worth developing any further.

Photo © Salim Virji, cc-by-sa.

Further thoughts on extending the window menu

The previous post about extending the window menu caused a great deal of discussion. It would seem that our readers would be interested in an implementation. Thomas is considering working on this after the window matching experiments are more stable.

Now, we can imagine that any package might want to add menu options when it was installed, and delete them when it was removed. Let us not concern ourselves for the moment with how a menu option and its effects are represented, other than assuming that it may be represented by an ASCII string. Rather, let us consider the ways in which a newly-installed application may wish to add menu options. We are concerned with two kinds of menu option:

∀: these appear on every window menu, for as long as the application is installed. It need not be running. For example, Take screencast should be available when Istanbul is installed and removed when Istanbul is removed.
∃: these appear only on the menus of windows created by the application itself. For example, Play should appear on Rhythmbox‘s window menu, but not on other applications’ menus, even if Rhythmbox is running. (Otherwise, how would a user tell the difference between Rhythmbox’s Play and the Play of Totem?)

Users should have the option of disabling any ∀ options which are currently installed; the full set of ∀ options would be available in some kind of settings dialogue where a decision could be made about which options belonged on the list. It should be noted that Minimize, Maximize, Close, etc., are the ∀ of the window manager itself.

So, where should these settings be stored?

In X properties on windows: The ∀ options would be stored as properties on the root window, and the ∃ options as properties on the windows involved. This would be the simplest to implement, but who has the responsibility to set the property on the root window, and where does the data come from?
In GConf: This would only work for ∀ options. It’s presumably a better plan than keeping them on the root window, though, and we could still use X properties for the ∃ options.
In /usr/share/applications/*.desktop: This is the way which would integrate best with package management, but would cause rather a performance hit as all the .desktop files would need to be scanned when the WM started up, and then there would need to be some kind of particularly clever window matching to work out which .desktop file corresponded to which windows for ∃.

Some kind of hybrid approach may be best: we could keep the ∀ menu options in .desktop files, and have a utility program that was run when any package was added or removed, to update GConf with the values. Or perhaps this updating could be done in the control centre, when the user chose which subset of ∀ options they wanted. Then we could keep ∃ options as properties on the windows, and rely on the toolkits to update them (perhaps even by parsing the application’s .desktop file).

Photo © van swearingen, cc-by-nc-sa.

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.

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.

Quick mention: a theme editor

Someone is working on a Metacity theme editor called Metacity Themer. It appears to take rather a different approach from Opacity; it’ll be interesting to see how this turns out. I’m not sure whether I should abandon Opacity; I wasn’t working on it anyway much (though I had thought about it quite a bit) and I don’t really have time to finish a theme editor anyway with the amount of work that Metacity needs, so Opacity would have been a while off prime time anyway. Let us know what you think of Metacity Themer.

another crazy idea

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

Squib of the day: walk through workspaces

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

Some of the tools

Here are some of the tools that ship in the tools directory of Metacity:

announce-wrangler.py
is the script that produces release announcements in both text form (for gnome-announce-list) and HTML (for posts like this one). It needs some polishing.

commit-wrangler.py
puts up an editor for a ChangeLog entry, then commits current changes. It used to be far more complicated, but now it’s merely a wrapper around a couple of calls to moap. Stable.

patch-wrangler.py
given an attachment number on GNOME Bugzilla, checks out Metacity trunk, downloads the given patch, applies it, and compiles. Stable, but it would be nice if it could pick up the author’s name and email address for the ChangeLog too. That will probably have to wait for a scriptable GNOME Bugzilla.

ppa-magic.py
is supposed to build personal package archives for Launchpad with nightly builds in. It doesn’t work at present.

release-wrangler.py
is our release script; it helps prepare the NEWS update from the ChangeLog, distchecks, builds, and uploads, but doesn’t actually run the update script on the server. I did think of replacing this with ShipIt at some point, but their model is too different from ours. Stable.

There’s also blog-wrangler.py which isn’t shipped, and produces the Metacity Journal, and is being gradually replaced by a more general version in Perl called ProjectJournal. Also, the Perl module Flickr::Embed grew out of the same project, though it isn’t yet in use.