Re: [Usability] main window position

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]