Window matching

glass pane, shatteredWindow 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.

Photo: Glass pane, shattered, © nchenga nchenga, cc-by-nc.

4 Comments

  1. Robin
    Posted November 3, 2008 at 1:03 am | Permalink

    Maybe a freedesktop.org specification could be created/extended to clarify what these three properties should look like with some examples. And I think making it a GNOME Goal would also be a good idea.

    So when all applications would correctly set these three properties, window matching wouldn’t be considered as black an art as it is now, right? Or are there other problems?

  2. Posted November 3, 2008 at 1:15 am | Permalink

    That’s pretty much it, yes. It would make life easier for Devil’s Pie etc even if we didn’t move its function into Metacity (which we might not do anyway for reasons given above).

  3. Killerkiwi
    Posted November 3, 2008 at 3:38 am | Permalink

    Pulse audio is going to need to tie into some thing like this long term… being able to set volume for the active window with a global key combo.. mouse wheel while on the windows title bar would be cool

    Second the freedesktop.org idea

  4. Hongli Lai
    Posted November 18, 2008 at 10:31 pm | Permalink

    For point (1), I think that there are only a few reasons not to use an out-of-process window matcher:
    1. Usability, ease and simplicity. The user doesn’t have to install/configure a separate software package. However, this can be solved at the distributor level by integrating the window matcher by default.
    2. Efficiency. Integrating a window matcher in Metacity might save you a few hundred KB of memory. The question is of course whether this is worth it. On a single user desktop, probably not. On a server which serves dozens of desktops to thin clients, maybe.

    1 is easily solvable, so unless 2 is important, it would make more sense to have an out-of-process window matcher.

    As for the other points, wouldn’t it be a good idea to apply to the window matching rule only if Role is set? Just ignore all clients that don’t set Role and treat them like before. I don’t think anybody would be annoyed by “different” Firefox windows (whatever the definition of that might be) appearing at the same place.