Re: Preserved Window Placement

[Federico Mena Quintero <federico gnome org>]

On Wed, 2012-10-24 at 16:38 -0500, Jason Simanek wrote:

> What if the window manager's API (pardon my lack of proper
> terminology) gave applications tools for identifying a primary window?
> For that matter, giving them a way to identify all of their windows.

This mechanism exists; it is the WM_WINDOW_ROLE property on windows.  By
default it is not set to anything.  The problem is that only some
applications set this property on some of their windows.  For example,
if I run "xprop WM_WINDOW_ROLE" a few times and click on a few windows
on my desktop, I see these values:

Evolution - "EShellWindow-40304784"

Evolution message composer - "EMsgComposer-48720352"

gnome-terminal (first window) -
"gnome-terminal-window-1485--390099286-1351203003"

gnome-terminal (second window) -
"gnome-terminal-window-1485-2121229713-1350417253"

Gedit - "gedit-window-1351203061-151009-0-quesadilla.site"

Gedit About box - not set

gnome-font-viewer - not set

gitk - not set

emacs - not set

Firefox window 1 - "browser"

Firefox window 2 - "browser"

Firefox window 3 - "browser"

Firefox bookmarks window - "Organizer"

Firefox About window - "About"

GIMP toolbox - "gimp-toolbox"

GIMP image window 1 - "gimp-image-window"

GIMP image window 2 - "gimp-image-window"

GIMP About window - not set

Yelp - not set

So, you can see a few things:

* Apps that don't set the WM_WINDOW_ROLE at all.

* Apps that set all their windows' role to the same string.

* Apps that set some of their windows' role to the same string, some
other windows' to another string, and some others' to nothing at all.

* Apps that actually try to use unique role strings for each window
(except for some - e.g. Gedit's document windows vs. the About box)

>From a window manager's perspective, there are three things that it can
use to try to identify windows:

1. The WM_WINDOW_ROLE property.

2. The WM_CLASS property (which most programs simply set to the
program's name).

3. The WM_NAME and _NET_WM_NAME properties (the former is historical and
rather deprecated; the latter actually supports UTF-8 window titles).

In theory, if the WM_WINDOW_ROLE were actually set for all windows and
actually unique, then the window manager could save and restore the
geometries perfectly.

However, since not all programs set this property to something unique,
window/session managers *have* been known to use different heuristics...
combining the WM_CLASS and the WM_WINDOW_ROLE, paying attention to the
window title (which is not very useful, since it changes frequently),
etc.

> Here's some info about OSX’s NSWindowController:
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindowController_Class/Reference/Reference.html
> 
> NOT THAT WE WANT TO MIMIC OSX. But it is a good example. Thinking
> about preserved window placement never even came to mind until I
> started using Linux, where it basically doesn't exist. In the history
> of Mac OS it worked consistently enough that I took it for granted. No
> point in recreating the wheel.

Hmm.  That page says this about [NSWindowController
setWindowFrameAutosaveName]:

"Sets the name under which the window’s frame is saved in the defaults
database. [...]  By default, name is an empty string, causing no
information to be stored in the defaults database."

I don't know if OSX uses something beside that parameter in
NSWindowController, but going only by that description, it would seem
that not all windows' geometries are necessarily saved.  (Or OSX may use
similar heuristics to X11 window managers, such as looking for the nib
file name or window titles... no idea).

So I don't know if the application-side infrastructure in OSX is
actually in any better position than X11's; it may be that they
*actually* save window positions all the time (for the windows for which
it is possible, anyway), and we don't.


I just looked at gnome-shell's code, and it doesn't deal with
WM_WINDOW_ROLE at all.

As for Mutter, it *does* deal with WM_WINDOW_ROLE.  Look at
mutter/src/core/session.c:save_state() and grep for "role" there.
However, this function is only called if the session manager asks Mutter
to save the session.

What you want is for the window manager to save this information
per-window as it changes, not only when the session ends or is saved.

It would be interesting to play with some patches to Mutter to do this.
To keep the list of windows/geometries from growing unboundedly, you
could make it keep only a certain maximum number of geometries, or
discard the ones older than N days, etc.

Would you like to try to implement this?

  Federico