Remember+restore window position of applications with WM_WINDOW_ROLE or window title set

[Doug Holton]

Open firefox or thunderbird. Move the window. Quit the application. Open the application again. The window is back over on the left again.
The mozilla team leaves window positioning to the window manager on unix/linux systems:
https://bugzilla.mozilla.org/show_bug.cgi?id=31086

The advanced settings to enable Gnome to remember window positions is not available at the place these instructions say they were a year ago:
http://ubuntuforums.org/archive/index.php/t-36505.html%3C/t-199815.html

A similar ubuntu bug was reported earlier, but it was about firefox only, and it is already marked as having been fixed in Feb., however, I am seeing the issue today using Feisty, which was released in April:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/65841

One possible workaround is using Devil's Pie: http://www.burtonini.com/blog/computers/devilspie
which requires hand editing xml files and creating pattern matching filter rules.

[Koen (koen-beek)]

I can confirm this behavior on Ubuntu Gutsy also

[Koen (koen-beek)]

same behavior with gedit (as for firefox and thunderbird) : size is remembered but not the position

[Koen (koen-beek)]

bug #157497 seems related

[Sebastien Bacher (seb128)]

gdm is the login manager, it has nothing to do with that, reassigning

[Trouilliez vincent (vincent-trouilliez-modulonet)]

Same here. I noticed this problem with Gnome Volume Control.
I always leave it opened, in the bottom left corner of the first desktop/workspace, but when I power up the computer, it always opens up in the top left corner, not bottom left. It does remember its window dimensions, though.

One thing I noticed, if that helps, is that as far as I can witness, this only happens when logging in for the first time (just after the machine has been powered up), but once logged in, if I log-out then back in again, the volume control window is restored properly.

Hope that helps...

[Pascal De Vuyst (pascal-devuyst)]

Looks like a window manager issue, reassigning to metacity.

[Marnanel Thurman (marnanel)]

Metacity won't fix this because:

1) it's not a window manager issue; applications ought to be responsible enough to create their windows where they want them;

2) it violates separation of concerns; there can be a separate process (such as devilspie) which moves a user's windows around to their heart's content (the difficulty of configuring devilspie itself is not a counterargument to this);

3) it's near-impossible to do well in the window manager anyway, since we don't have any good way in X of recognising that the new window is somehow "the same window" as the old window. Only the application knows that.

[Pedro Villavicencio (pedro)]

marking it as wontfix then as per Thomas comments. thanks.

[Denny de la Haye (dennymeta)]

I have re-filed this bug as part of the 'hundred papercuts' initiative to improve UI usability for 9.10. Anybody who was following this bug may be interested in adding their thoughts/support on the new one:
https://bugs.launchpad.net/hundredpapercuts/+bug/391533

[Vish (vish)]

@Denny de la Haye:

Please do not re-file bugs. If the metacity devs wont fix it , the papercuts team cannot do it either, As in the end, it has to be fixed by the metacity devs only.!

[Denny de la Haye (dennymeta)]

WRONG. Have you even read the bug report? The bug is not only in Metacity, therefore it's not only down to Metacity devs to fix it. Compiz has the same problem, for instance.

Integration of Devil's Pie with GNOME seems like the most obvious solution to me, but someone else might have a better idea.

[Doug Holton (edtechdev)]

Over a hundred people have voted for this feature over on the ubuntu brainstorm site:
http://brainstorm.ubuntu.com/idea/1442/
It should at least be kept an open issue I think.

[Tibor Gáts (tiborgats)]

I have the same problem with a lot of applications, and things like file-open windows, etc. In many cases the window size is smaller than I set before. It is VERY ANNOYING for me, when an application's window doesn't keep the size and position I adjusted, and I have to adjust it again and again and again.... It is HORRIBLE!!! I get really angry even thinking about it!!
Please try to imagine this situation: I have a huge monitor (1920 x 1200), and when I want to open a file, a small window appears which shows sometimes 5 percent of my files in a folder. Than I have two options: scrolling a lot, or resizing the window. Resizing would be better, if it would be kept for the next time. When I use the computer it takes at least 25% of my time always resizing windows!
WHY are my settings not kept??? Why isn't there any option to keep my settings??? I would like to have this option for ALL the windows, dialogs, etc.

[Marnanel Thurman (marnanel)]

Robert Ancell asked me to look into fixing this in Metacity. I've started to work on it:

http://blogs.gnome.org/metacity/2009/07/10/matches/

[Vish (vish)]

Won't Fix in papercuts , but is tagged "ayatana" to be overseen in Ayatana project

[erlguta (gonzalomarcote)]

Is unacceptable that gnome does not have this option in 2010.
With gnome developers saying all the time that this should be implemented by applications devs and applications devs not doing it, we may move on without this functionality, so BASIC!!, until 2020.
I am bored every time i power on my computer to place my apps (gnome-terminal, evolution, firefox) and resizing / maximizing to be how i want.
And this, all the times, all the days, again and again. Frustrating...
This is one reason why I seriously thought to stop using gnome.

[James Lewis (james-fsck)]

This is definitely expected behaviour for Windows users... but although I agree that it is somthing which should be addressed... I use a more cluttered approach to managing desktop windows, and I much prefer the current behavior of placing a new window in the least occupied area of the screen... so as to minimize overlap.

If this feature is added, (And I think it should be)..... it should be an option which is configurable.

[Denny de la Haye (dennymeta)]

Metacity doesn't do a very good job of minimising overlap - it places windows firstly into any empty space which is big enough for the entire window, and if there isn't a space big enough to do that, it places the window at top-left regardless of where the largest remaining space is on the screen. Sawfish used to work the way you're thinking of, placing things into the biggest remaining empty space even if they didn't quite fit there. I do agree placement behaviour should be configurable though.

[tellapu (tellapu)]

I was also searching the net for a simple fix for this problem, but I was disappointed. Even the lightweight window manager fluxbox can do it, why not gnome (which I so far liked):
http://manpages.ubuntu.com/manpages/maverick/man5/fluxbox-apps.5.html

Hopefully it is not too difficult to add this function.

[Martin Spacek (mspacek)]

Just a note, compiz seems to do a slightly better job of remembering window positions than metacity, but only for some apps it seems. Positioning of Audacious (mp3 player) was terrible under metacity, but under compiz it's perfect. See duplicate bug #409539.

[tsg1zzn (tsg1zzn)]

This is not the job of the window manager, it must be fixed in the applications themselves.

It is also my opinion that saving of windows position and state (maximized/restored) should be detailed in the gnome HIG. This way developers will be more obliged to fix it. Because currently reporting this to devs it will get a low priority, even wishlist. Which in my opinion is ridiculous, as this is a very important and basic feature.

How would you like it if your computer was randomly hidden somewhere in your apartment every day when you woke up? You'd be furious after a week or two. This needs to get into the HIG!

[Denny de la Haye (dennymeta)]

"This is not the job of the window manager"

Why? Devils Pie shows that this can be handled at a higher level, and indeed it seems to me to make much more sense to handle it at a higher level - then you can handle overlaps etc in a graceful fashion.

Just because remembering window placement isn't currently handled by the window manager (and really, doesn't that sound weird to you?!), doesn't mean that shouldn't change if by changing it we can improve UX.

[tsg1zzn (tsg1zzn)]

This is not the job of the window because it can't possible done correctly in the window manager. It's that simple. I'd love to have this working correctly in the window manager, but it's logically impossible without application support. Because the window manager doesn't have any way to know that a particular window is "the same" as another.

Devils Pie doesn't work correctly. It uses the names of the windows and the name of the program. Both of these will inevitably fail, as the window title may change according to the document open, the current folder, the current language, and many other factors. Devils Pie has a sophisticated rule system to get around this, however these rules have to be created by a human who knows what he wants. They can't be generated programatically and still do the right thing every time.

It is my opinion that the 100% proper way to handle this would be that the applications could specify a unique id for every window or window "class". Then the window manager could remember the positions correctly.

Maybe X atoms could be used for communicating this ID to the window manager. If the window manager doesn't support this convention, no harm, if an application doesn't support this convention, no harm. But the unfortunate point is, that it still requires application support.

Because currently, applications don't specify anything that would allow the window manager to properly know that some windows are "the same" despite a different window title (and that some windows are not the "same" despite similar window title). And since it can't possible be done correctly in the window manager we have to do it in the applications.

[tsg1zzn (tsg1zzn)]

Correction: Devils Pie doesn't work correctly for this purpose. It does correctly what it does, but it does not have the capability wished for here.

[Matthew Paul Thomas (mpt)]

If it can't possibly be done in the window manager, this bug should be Invalid, and bug 409539 should no longer be a duplicate.

[Denny de la Haye (dennymeta)]

"If it can't possibly be done in the window manager ..."

See comment #14 - someone already made a good start on it last year. All it needs is someone to care enough to try, instead of jumping on the opportunity to write the bug off as invalid.

[tsg1zzn (tsg1zzn)]

Denny de la Haye, you seriously need to understand the technical details better before you can know whether it can be done or not.
The code in coment #14 requires that the application set WM_WINDOW_ROLE properly. If all applications did that, implementing this feature would be trivial.

The problem is that many (most) applications don't do this. In fact when quick testing a few applications I could not find ANY that did this. Which brings us back to what I said: This REQUIRES some application level support.

This doesn't mean this bug is invalid as such, because the window manager could provide one part of it. But it will not work without some application support.

[Paul Sladen (sladen)]

See documentation for gtk.set_role() for how to add this to applications:

  http://www.pygtk.org/docs/pygtk/class-gtkwindow.html#method-gtkwindow--set-role

[James Lewis (james-fsck)]

OK, so that's the answer then isn't it... have whatever library is involved return a warning if WM_WINDOW_ROLE is not set, and then implement it in the window manager if that value is set... It's not unreasonable for the application to be required to do that kind of thing... But I think it probably is unreasonable for every application to have to implement a different way to store the location and restore it itself tho.

[Paul Sladen (sladen)]

James: re: "then implement it in the window manager", could you suggest what those heuristics would need to be? In this case it's going to probably be harder to implement it, than to design what "should" happen, ie what heuristics should be used. If you can specify those it would be easier to follow what you might have in mind.

[James Lewis (james-fsck)]

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

[Denny de la Haye (dennymeta)]

"The code in coment #14 requires that the application set WM_WINDOW_ROLE properly."

That's not a reason to make this bug invalid then, is it? In fact, quite the contrary. If this bug is marked invalid, and no WM (or DE) level support for placement is ever added, there's little incentive for applications to address their end of things.

If this support existed, I'd be very happy to start filing bugs on applications saying they should be supplying the necessary info, but until then they're going to say 'why?' and guess what, yes, mark it invalid or wontfix. It's like a game of hot potato played on multiple bugzilla instances, it's quite tedious and disheartening from a user/advocate perspective.

[Denny de la Haye (dennymeta)]

Paul, thanks for the bug title update.

[tsg1zzn (tsg1zzn)]

"That's not a reason to make this bug invalid then, is it?"
Not really (and it wasn't me who did that). It's a good solution that we force every application to set WM_WINDOW_ROLE properly and handle the saving and restoring of position in the window manager.

Btw. there needs to be a maximum number of window types remembered (like 500) or the database would grow forever due to applications that set WM_WINDOW_ROLE to include random numbers (I'm looking at you, gnome-terminal) and similar unexpected things.

[Eric Walker (email-owlcroft)]

First, let me disagree violently with whoever classed this problem as "Low" priority: it is, as others have already noted above, a real productivity killer, on a system-wide basis, to have to be constantly rearranging already arranged windows every time one opens an app anew (not to mention the monstrous aggravation factor from lack of a major feature that was considered basic in pretty much every other OS on the planet a decade or more ago).

Second, since--as best I, a non-techie, can deduce--it seems that the solution is obvious (use WM_WINDOW_ROLE) and, I gather, not difficult of implementation ("If all applications did that, implementing this feature would be trivial"), whatever is holding up implementation? It seems everybody is sitting around the campfire nodding "Yup, right, easy-peasy", then walking away humming a tune and leaving nothing done about it.

Can we please get the implementation into the window manager ASAP? Then the world can go to work on the app developers, who will have zero excuse for not implementing proper use of WM_WINDOW_ROLE (and will probably, by and large, be delighted to do so).

The world watches and waits . . . .

[dreamon (dreamon)]

The last weeks have seen a lot of discussion on the bug, and it seems the general consensus is that this behaviour isn't desired by most users and is, in fact, a major issue for most people. People have pointed out that this feature is very standard in most major operating systems and there seems to be a common desire for a quick and stable solution to this problem.

Apparently, the window manager isn't the only one at fault, but changes in the applications' handling of window positions/size are required as well. However, there seems to be room for improvement in the window manager -- which is only reasonable, since obviously these things work well with other window managers. Considering the importance and visibility of this issue, would it perhaps be possible to include this bug in the "one hundred paper cuts" project? -- provided this issue fits the scope of the project.

https://bugs.launchpad.net/hundredpapercuts
http://www.omgubuntu.co.uk/2010/12/get-involved-with-the-one-hundred-paper-cuts-project/

[Denny de la Haye (dennymeta)]

dreamon: See comment #9, and bug #391533 - I did file (a more general version of) this bug against 100 Papercuts. It was initially rejected for the usual storm of glib "somebody else's problem" and "it's a feature, not a bug" reasons, but in the end 100 Papercuts rejected it because it's not simple enough to fix (100 Papercuts is intended to pick off low-hanging fruit, basically).

Somebody else did assign that bug to Ayatana, which I think is a usability project with broader scope/ambition than 100 Papercuts (but accordingly, less chance of things actually happening).

[Doug Holton (edtechdev)]

I don't think this should be limited to just cases where WM_WINDOW_ROLE is set. As someone else commented, virtually no applications have WM_WINDOW_ROLE set, and so only remembering window positions for apps that do set it would not really address the problem.

Also, from the docs that someone linked to on how to set the role:
http://www.pygtk.org/docs/pygtk/class-gtkwindow.html#method-gtkwindow--set-role
It says: "If a window already has a unique title, you don't need to set the role, since the WM can use the title to identify the window when restoring the session."

So I'll adjust the title of this feature request to check for WM_WINDOW_ROLE or a window title.

[Denny de la Haye (dennymeta)]

Wasn't the point made above that window titles are insufficiently (a) stable and (b) unique for them to be used as the hook for remembering placement?

[Ed Lin (edlin280-deactivatedaccount)]

I've added Compiz to this bug as per the discussion here:
https://lists.launchpad.net/ayatana/msg05613.html

>I know about the window placement plugin in CCSM but there are two problems:
>It requires manual setup and can only do static coordinates and rules
>whereas it should be enabled by default, transparent and dynamically
>remember positions.
>Secondly, it's broken. Opening another window of the same
>class/role/whatever shouldn't put it exactly on top of the other one
>but cascaded so both titlebars are visible. See KDE, Windows and OS X
>for a correct implementation.

[...]

>My recommendation for the near future: Extend the window placement
>plugin so it supports cascading (or "smart" placement, see below) of
>same windows and automatically remembers coordinates. Once it's deemed
>stable and functionally complete enable it by default.

Please see the mailing list for further problems and ideas surrounding the issue.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[les (lesion)]

FYI, I'm working on an indicator to store windows placement.

https://github.com/lesion/indicator-placement

please feel free to contribute

[fcole90 (fcole90)]

As part of the big bug clear up for 16.04 this bug is being marked as Opinion. While this bug is affecting you, and potentially others, we are not considering working on it so it won't get fixed by us. Other developers are free to pick this up and work on it. Sorry that we can't offer you help at this time.

[James Lewis (james-fsck)]

This is perhaps a perfect example of the issue many people have, and which people I've converted to Ubuntu complain about (to me), on a regular basis...

Reading the history of this bug, it seems that a consensus was reached on the correct solution, in 2010, but we are fast approaching 2017 and nothing has changed.

Hopefully Unity8 will address some of these issues, and render this 10 year old bug finally resolved by virtue of being obsolete.