Comment 31 for bug 124315

I'm sure that Denny will have input here, and I'm concious that this question sounds a little like a trap to point out where I have overlooked the reason this would be a problem.

So, lets start from first principles...

The thing that this thread contends is that each application should not have to independently implement a window location management function itself. This would waste resources, never be fully implemented and would be inconsistent in it's behaviour as well as not globally configurable. It does not I believe, contend that this should happen by "magic" without any kind of co-operation from the app. If that co-operation needs to be the setting of a parameter (WM_WINDOW_ROLE) which would identify that window so that the window manager could have a reliable point of reference.

Firstly, I would suggest that in the window manager configuration... there should be an option which might be labeled "Window positioning policy"... ( Right next to the "click to raise" button which has been missing for years now :p )

After that, when the last window of a given role is closed, the window manager would store it's dimensions and location, probably in gconf, although I don't know if there is an abstracted API for storing data which might work with KDE or other environments also. Then when the first window of that type is subsequently opened, perhaps after a reboot... it should be opened with the same dimensions and location as the last one to be closed. (i1f the screen resolution, or number of screens is no-longer the same such that the window no-longer fits on the screen, it should revert to dynamic positioning)

I would suggest that other people might like to comment on what the correct behaviour for subsequent windows of the same type which are opened before the first is closed, but I believe that it should be of the same dimensions, and it should be positioned somewhat near, but offset from the original, on the same screen.

~James