Re: [Usability] main window position

[Matthew Paul Thomas <mpt myrealbox com>]

On 30 Dec, 2005, at 1:51 PM, Steve Fosdick wrote:
> Matthew Paul Thomas <mpt myrealbox com> wrote:
>
> > You should report this as a bug for each program. It's a basic part 
> > of a spatial interface that all windows (other than alerts or 
> > dialogs) should remember where you left them.
>
> Does this include which workspace the window was on?

That's part of "where", yes.

> ...
> > The window manager could do most of this, except that it can't know 
> > which document is associated with which window. For example, if you 
> > close a document called "Annual Expenses", then rename it to 
> > "Expenses 2005", then later reopen it, it should have the same window 
> > position as it did last time -- but the window manager won't know 
> > it's the same document.
>
> What that suggests as a possible architecture is that for any 
> top-level window the window manager should be able to give the 
> application something opaque that represents the current state of the 
> window (position, size, workspace etc.) that the application saves as 
> part of the document.  When the document is re-opened this gets handed 
> back to window manager to set the size/position of the window 
> correctly.

That's a possibility, but it doesn't handle the case of a non-document 
window (such as wanting the Calculator to open in the same place each 
time), or the case where a document is read-only (so you can't store 
window position in the document itself), or the case where a document 
is worked on by multiple people who want the window in different places 
on their respective displays.

Another approach would be an extra window manager hint. Without the 
hint, whenever a window was closed, the window manager would remember 
the window's position using records of the form {program, window title, 
window position, timestamp} in a hidden file in your home folder. (This 
satisfies the non-document use case, and the use cases of files that 
are read-only and/or accessed by multiple people, because the window 
position isn't saved in the document itself.) The timestamp field would 
let the window manager cull records that are older than one year or so, 
so that the file doesn't grow without bound. (If you haven't opened a 
program or document in the past year you almost certainly will have 
forgotten what its window position was, so it won't matter that the 
window manager forgets too.)

The extra hint would be a way for a program to tell the window manager 
"this is the pathname of the document open in this window". When told 
that, the window manager would also get the inode of that document if 
it was local, and then remember {program, pathname, inode, window 
position, workspace, timestamp} instead of {program, window title, 
window position, workspace, timestamp}.

When given the pathname for a window being opened, the window manager 
would look up the pathname in its list to see if it knew what the 
window position was supposed to be. Failing that, the window manager 
would get the inode of the pathname if it is local, and look up that 
inode in its list too (this handles the case of a renamed document). 
And failing that, it would use a default window size and position.

Since remembering window positions is quite a subtle thing, application 
developers might well not bother to implement such a hint. But they 
could be greatly encouraged to bother by it being exactly the same hint 
that lets the window manager implement a draggable proxy icon in a 
document window's title bar (as implemented in most document-based 
applications in Mac OS 8.0 and later, and also in Internet Explorer 5.0 
and later on Windows). Given the path of a document, the window manager 
would know how to get the icon of the document, and make it draggable 
in the same way Nautilus does. (There would be other tricky issues to 
deal with when introducing this feature, though.)

> Of course there is also the case of an application started without a 
> document (or with a new, blank document).

That would be covered by the approach described above; since the 
window's title was "untitled" and no real path was supplied, the window 
manager would use the same position as that program's last "untitled" 
window had when it was closed.

> Also if someone chooses a document from the file/open menu and that 
> document has stored window position information should:
>
> 1. The document be openned in the application's current window and the 
> size/position information ignored.
> 2. The document be openned in the application's current window and the 
> size/position information used, i.e. the window moves/resizes 
> accordingly.
> 3. The document is openned in a new window, leaving the initial, blank 
> document on the screen?
> ...

I think #2 would make the most sense, though the mere existence of that 
question is a problem with the application-and-filepicker idiom.

--
Matthew Paul Thomas
http://mpt.net.nz/