EWMH – …for the adult in you

Come calm content serene and sweet

Most themes place the icon of the current application somewhere on the titlebar. Some operating systems (notably OS X) allow you to drag this icon as if it was the very file which is being viewed in that window.

This behaviour has been suggested for Metacity in the past. One of the two main problems with implementing it is that we have no way to identify the document being viewed in a window; we only barely have a way to identify the application.

In a blog post last week, Michal Hruby suggests a new window property to indicate the URI of a window’s current document. This spilled out onto wm-spec-list this morning. (“NEW” in the title is a typo for “NET”.)

Such a property is a matter for the toolkit to set, rather than the window manager. But if it was available, it would make the lives of window managers a little easier: not only would it make the window icon dragging possible, but it would also allow window matching by document or even document type, as well as by application.

Photo © Glamhag, 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.

On enhancements which need changes to the EWMH

Some of the enhancements which have been suggested need some sort of hint to be set on windows. For example, the recent squib about a special style for warning windows could only work if warning windows were marked in some way, and at present they’re not. Similarly, drag and drop can only work better if the window manager is warned which clicks start a drag and which don’t. This too will need a new hint.

There are two ways this can be done. The simplest way is to use a hint whose name begins _METACITY; this doesn’t require us to talk to anyone. It’s sometimes one way of starting the process of adding a feature like this. Of course, it means that the feature’s unlikely ever to work with any other window manager.

The better and more extensible way is to make a new standard hint, one beginning _NET_WM. This means adding the hint to the Extended Window Manager Hints standard (the EWMH). Changing this standard means arguing it out on the wm-spec list. The maintainers would like not to be the only ones to raise new ideas on this list.

In either case, the toolkits (such as GTK) will then need to be updated to mark the relevant windows with the relevant hints, and finally the applications will probably need to be updated to use the new functionality in the toolkits. You can see, gentle reader, that enhancements like these are the source of more work than the average enhancement. They may nevertheless be worth the effort.

This entry exists mainly so that we can link to it when the issue comes up.

Photo © !!sahrizvi!! (back in Dubai) !!, cc-by-nc-nd.

Squib of the day: Special frame style for warning dialogues

GNOME bug 102548 suggests that warning dialogues should have a special frame style, and it’s suggested that this could look like safety tape wrapped around the edge.

This is not unlike the special frame style suggested here for root windows. However, while there’s already a way for the window manager to tell whether a window belongs to the superuser, there’s currently no way to tell whether a window is a warning, so this would need a change made to the EWMH and then need all the toolkits fixing to use it. It’s thus rather nontrivial, although it may still be worth it if it helps users.

Because this requires a change to the theme format, it must be committed first on a branch.

I am seriously entertaining the idea of doing away with the window and frame_style_set tags in v3 of the format, and just using tags on frame styles such as maximized, shaded, focused, unfocused, root, warning, modal, and so on, with some well-defined and intuitive rule about how to break ties:

<frame_style geometry="foo" tags="border focused maximized"> <piece position="title"> ...

Photo © Robin Gallagher, cc-by.

Squib of the day: Drag and drop should work properly

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

Metacity and D-Bus

GNOME bug 531512 suggests that Metacity should have a D-Bus interface. On the face of it, this is a good idea. However, the problem lies in the existing EWMH specification, which allows a program to request operations from a window manager– simply put, it’s pretty much exactly what a D-Bus interface would be, but it already exists. If we also exposed a D-Bus interface, even one called “org.freedesktop.WM” instead of “org.gnome.Metacity”, we wouldn’t be gaining anything we don’t already have, and then people would begin using it and their programs wouldn’t be compatible with other EWMH window managers. So every WM that implements the EWMH would have to expose the same D-Bus interface, which sounds like a lot of work for not much return. On the other hand, we could have a separate program which exposed a D-Bus interface which translated the methods into EWMH messages, and which could be used with any EWMH window manager. Would that do as well? What do you think, gentle reader?

Photo copyright Zarko Drincic, cc-by-nd.

Notifisation

Listen to this.

Launchpad bug 124326 requests a new titlebar button which minimises an application to the notification area rather than ordinary minimisation. Mostly this is currently done with the close button on the apps which support it, but some people feel it would be cleaner if these two functions were distinct. This action has been given the name “iconification” by some, but since this is the name the X specification gives to what we now call minimisation, I propose the ugly word “notifisation”.

There are four problems with this idea.

Adding new titlebar buttons is always problematic for reasons given earlier.
The EWMH specification is going to have to include a way to tell which apps may be notifised, and a way for the WM to tell an app to notifise itself. This is going to require arguing out on wm-spec-list. In itself, this is not a major obstacle, but it’s important to be aware of.
It is unclear what the real difference between minimisation and notifisation is in practice. And if there is one, why shouldn’t all apps be notifisable?
Using the notification area for things other than ephemeral notifications– that is, using it as a cheap way to make panel applets– is contrary to the Human Interface Guidelines. Perhaps the HIG is wrong, but then we need careful thought before we give the practice a stamp of approval by enshrining it in the EWMH. Besides, there is talk of enforcing notification ephemerality.

Photo by The Joy of the Mundane, cc-by-nc.

Window matching

Window matching is the process of identifying a new window as one we’ve seen before. Of course every new window is new, and so we’ve never seen it before, but there’s an intuitive understanding that if you open a document in OpenOffice and then come back to it a week later that the window is in some way the same.

Some good properties to use for this are:

SM_CLIENT_ID, which is set by the session manager for a particular instance of a running program. XSMP says that “a unique value called a client-ID is provided by the protocol for the purpose of disambiguating multiple instantiations of clients.”
WM_WINDOW_ROLE, which is optional. The ICCCM says that “the combination of SM_CLIENT_ID and WM_WINDOW_ROLE can be used by other clients to uniquely identify a window across sessions.” If there is no WM_WINDOW_ROLE, the ICCCM tells us to fall back on WM_CLASS and WM_NAME…
WM_NAME is the window title.
WM_CLASS is a two-part property. Let’s call these Instance and Class, although these aren’t the real names. Instance is generally the name of the program, although it can sometimes be set on the commandline.
Class is “the general class of applications to which the client that owns this window belongs”, i.e. the brand name of the program (rather than “editor”).

Metacity does not currently do window matching for three good reasons.

1. Separation of concerns: in-process or not?

The EWMH allows us to do window matching outside the WM, and in fact this is what Devil’s Pie and gdevilspie are for. They have all the other problems, but they’re not part of the WM, and if they crash they don’t bring the WM down. It appears that because this can be done outside the WM it should be. (Isn’t this fun? We can pretend we’re the Hurd.) Feel free to argue the point, of course.

2. Separation of concerns: app or WM?

It is also possible that nobody except the application itself knows where its windows should be placed, and that everything should be left up to the apps (and in practice the toolkits). This would allow us to do away with session management entirely. Certainly it would mean that it was none of Metacity’s business.

3. Paucity of distinguishability: who sets what?

Devil’s Pie requires you to set up rules to identify windows. Doing window matching at the window manager level implies that the rules are written for you automatically. This wouldn’t be a problem, except that applications set the attributes above very inconsistently. Although WM_NAME is always set, it isn’t necessarily reliable– for example, gedit adds a star to it when you begin editing a document. I believe therefore that we cannot use it in automated window matching.

As to the others, let’s introduce a notation: Role|Instance|Class. If Role is missing, we write [NONE]|Instance|Class. Here is a program called same.c which will print these values for you. Some common examples:

Firefox sets browser|Navigator|Firefox in all cases. It is therefore not possible to distinguish Firefox windows from one another except by WM_NAME.
Thunderbird sets [NONE]|gecko|Thunderbird-bin, but it usually only has one window open.
nautilus sets [NONE]|nautilus|Nautilus and it is therefore impossible to tell the difference between Nautilus windows except by WM_NAME.
inkscape sets [NONE]|inkscape|Inkscape similarly.
gnome-calculator sets [NONE]|gnome-calculator|Gnome-calculator.
gnome-terminal sets gnome-terminal-SOME-LONG-STRING-OF-NUMBERS|gnome-terminal|Gnome-terminal with the string of numbers different each time. This gets an A.
epiphany sets epiphany-window-SOME-LONG-STRING-OF-NUMBERS|epiphany-browser|Epiphany-browser with the numbers differing. Another A.
The GIMP sets gimp-XXX|gimp|Gimp where XXX is “toolbox”, “dock”, “tip-of-the-day”, etc. This gets an A+.

Please feel free to comment with more results and I’ll add them.

Conclusion

People often complain that Metacity doesn’t do window matching.
There are many reasons why it shouldn’t (but feel free to disagree in comments).
Window matching of any kind is needlessly difficult because the important properties are set inconsistently.
Therefore for the sake of window matching in general, whether we do it in Metacity or not, it would be a useful exercise to patch all programs which don’t set roles as well as the GIMP does. (gtk_window_set_role() is the relevant GTK function; it’s not widely used.) Perhaps this could become a GNOME Goal.

Communicating with Metacity

Quite often people ask whether Metacity can talk to you across D-BUS, or something similar. It can’t. There is no need for this, because you can do pretty much anything you want using X messages. In particular, you can use messages from the EWMH specification to perform pretty much any task you might want, and there are some additional Metacity-specific ones (such as an instruction to change the theme).

If you want to play with a client which can send these messages, I recommend wmctrl. Try installing it (it’s in most distros, I think), and then playing with it to see how you can

switch desktops
bring a window to a desktop
resize a window
maximise a window
minimise all windows
list all windows
rename a window
… and so on.

Read its source for all the details; it’s quite clearly laid out.

If the user will not come to the window, the window shall come to the user

Suppose you have two workspaces, and a window on each one. You’re looking at window A, so clearly window B is offscreen. You click something on window A, and window A attempts to present window B to you. What does that mean?

Let’s have two concrete examples:

0x01: You’ve clicked a link in Pidgin’s buddy window, and it’s attempting to present the chat window to you.
0x02: You’ve clicked a link in Evolution, and it’s attempting to present Firefox to you.

In 0x01, you want to stop looking at the old workspace and look at the new one. But you don’t want the windows to move off their workspaces. You want everything to stay where it is.

This is the way upstream Metacity currently works throughout. However, since Firefox is a tabbed browser,((I know Firefox has had tabs since 2002)) people have been asking whether this is the wisest course all the time. In case 0x02 above, in the old days, the browser would just have launched a new window in your workspace. People don’t like that now, because they want all their tabs in the same window. But if the user gets shoved onto the workspace of the existing window and then we add a new tab, eventually they’ll close it and then wonder where their mail went. (At least, that’s how I understand their argument; perhaps I’m mistaken.) As a compromise, downstream Metacity has now been patched in Ubuntu, Fedora, and possibly other places to make the window demand attention when this happens (i.e. go pulsy on the taskbar).

So we have multiple options when this happens:

Bring the window to the user, always.
Bring the user to the window, always. (This is what we do now.)
Make the window demand attention– in other words, apply the downstream patch. This is not the path of least resistance, since judging by recent feedback it appears to really annoy anyone using, say, Pidgin.
Tell the target application to deal with it. This would mean that Firefox could open a new window if you were on a workspace where it had no windows open and open a new tab if you were on a workspace where it had one already. It would mean finding some way of dealing with windows that didn’t co-operate. It would also mean, alone among all these solutions, that we’d have to find a way of communicating with the target application.
Ask the summoning application to give us a hint as to which of these it would like. This is my (Thomas’s) favourite solution. It will need a change to the EWMH.

Things which are not solutions:

Allowing the user to pick one and then requiring them to stick with it. As Havoc said, this is basically giving them a choice between “break Pidgin” and “break Firefox”.
Window matching. We do not do window matching. We are not about to start for an issue as small as this. That’s what devilspie is for.

Want to join in the ~~argument~~ fun? Dive in at GNOME bug 482354. The water’s lovely.

Photo credit: rofanator.