Application windows do not restore to last known position.

Bug #391533 reported by Denny de la Haye on 2009-06-24
This bug affects 18 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts

Bug Description

When you close an application window, and then reopen it at a later time, it does not restore to the previous location. This is the expected behaviour for anybody who is used to using Windows. It has been reported multiple times in the past, and is always marked WONTFIX because everybody claims it is somebody else's problem. This is not good enough.

This IS an issue, and somebody needs to step up for fixing it. On Windows, all application windows, dialogs, etc will re-load in the same position they were in last time you used them. This is predictable and consistent - a basic UI principle. Our 'best fit' algorithms on Linux don't come close to producing the same kind of usability.

I'd be very surprised if everybody who develops an application on Windows writes a chunk of code to handle remembering their window positions when they are closed and subsequently re-opened - it seems obvious to an end-user that this is the kind of thing that should be largely handled by a common piece of functionality resident in the window manager or the desktop environment. Obviously these distinctions are quite blurred on Windows, but the fact that we have better separation of concerns does not mean all the developers involved should be able to spend years passing the buck to some other team and marking this bug as WONTFIX, and that is exactly what has been happening ever since GNOME moved from Sawfish (which handled this 'correctly' from a user perspective iirc) to Metacity (which doesn't, and neither does Compiz).

To address the WM developers' complaints that this "isn't their problem", whilst also addressing the absurdity of expecting every application developer to address it individually (never going to happen), I believe this should be probably be handled by an invisible background application instead - that just sits there memorising window positions and restoring them when appropriate.

Please, somebody, write this daemon and offer it up to the Ubuntu project, because until you do, we're lagging behind on a very basic UI feature.

I'm filing this bug as part of the 100 papercuts initiative - I believe it's a perfect example of the sort of UI flakiness that long-term Linux users have got used to, and they don't realise how much it dismays and annoys newcomers.

Denny de la Haye (dennymeta) wrote :

Brainstorm thread about this problem, with quite a few comments and votes:

Previous report of this bug, closed WONTFIX, due to being "somebody else's problem":

Denny de la Haye (dennymeta) wrote :

Forgot to mention, the existence of Devil's Pie* is what makes me think that this also satisfies the 'relatively simple' criteria for 100 papercuts - there's an existing codebase that does some (most?) of what is needed, it just needs polishing up, integrating and automating, instead of users having to hand configure it for each window.


Denny de la Haye (dennymeta) wrote :

Sorry about the tag spam... apparently when you edit the bug description, launchpad removes the tags. Yay, meta-bug.

tags: added: usability
description: updated
tags: removed: usability
tags: added: usability

This is just to show my support ! Definitely a little thing that would give a better "polish" feeling to the UI, crossing fingers ! ;-)

Vish (vish) wrote :

I'm not sure which apps you are talking about, could you be more specific?

This was a problem for me in Hardy ever since I fresh re-installed Intrepid I dont have this problem.
At present in Jaunty, *I DO NOT have this problem* ... *All my programs remember the last position*...

If any problems it might be due to compiz settings[ccsm]> Windows Management > Place windows...
Enable the plugin and set it to "Smart" placement mode.
This[usually is enabled by default] controls the windows placement of a lot of windows and i believe the default is "Random" , Maybe your the problem lies there...

And FYI:
devilspie has a GUI >

Denny de la Haye (dennymeta) wrote :

Hand-configuring Devil's Pie on a per-application basis with a GUI isn't a great step up from hand-configuring it on a per-application basis with a text file, but thanks for the link anyway.

I have just installed CCSM and set my window placement to 'smart' (it was already set this way actually). I then opened a terminal, moved it, and closed it. I then opened a terminal again and it appeared back where it did the first time, not in the location I had moved it to before closing it. Same problem can be demonstrated using the 'chess' game, so it's not specific to the terminal. So no, that doesn't fix this bug. Can you see if you can reproduce this 'wrong' behaviour, or if you have some other setting making your placement work in the way the bug requests?

Personally I'm fairly sure that the 'smart' setting tries to place windows into the 'best' gap for them, not in the same place you had them last time. If you're seeing the latter behaviour then I think you have something else causing it, or you were testing with applications that work around this problem in the window manager.

Vish (vish) wrote :

@Denny de la Haye:

For terminal: maybe you use only 1 terminal , but several users use many terminals at the same time, so opening all of them in the same place is NOT IDEAL. Hence the present behavior for terminal is good as it is

Regarding games, I'm not able to test it I have removed all games , So cannot test it with that...

You can also set the window placement as "centered" ... But i guess you are looking for specific placements...

I have tested with all the apps i have and they remember the position,

 If it is a problem with Chess/games or a few handful of apps then, as you have pointed out also, the Metacity devs are correct "The apps need to correct this" , and not the metacity...

hence i'd suggest that you file the bug against specific apps, rather than as a papercut.

I'm marking this as a dupe and invalid [Due to the earlier metacity devs position regarding this issue]

Changed in hundredpapercuts:
status: New → Invalid
Denny de la Haye (dennymeta) wrote :

No, it only works with a handful of apps, those that have worked around the lack of appropriate behaviour by the window manager. There are even inconsistencies inside some apps, for instance GIMP will place some dialogs at 'last known' position and others at random positions, demonstrating why a per-application solution is not the correct approach.

Also, how can you mark a bug as invalid when you haven't even tested it against the reported behaviour?! My report is correct. The fact that you don't have the applications installed to test that doesn't make it invalid, it means you didn't validate the bug report properly. The same behaviour can be demonstrated with any application that hasn't worked around this bug!

Applications that don't work, from the first three folders on my Applications menu, skipping 'Games' as you seem to think they don't count just because you don't have them installed:
* Character Map
* Disk Usage Analyser
* Manage Print Jobs
* Passwords and Encryption Keys
* Take Screenshot
* Terminal
* Text Editor
* Evolution
* Firefox
* gFTP
* Remote Desktop Viewer

Applications that do work, from the same menus:
* Calculator
* F-Spot
* OOorg Draw
* Pidgin
* GIMP (main windows, although some dialogues drift around)
* Xchat

As you can see, this is not an isolated problem, it's more than half the applications that don't work. The ones that do work are generally the mature applications that have been around so long and had so many user complaints about this behaviour that they fix it themself, even though it should be fixed higher up the chain. They're also largely the ones with 'odd' UIs - GIMP, Pidgin, OOorg, none of these are particularly 'standard' applications, visually speaking. I guess their devs are more willing and able to get involved in messy windowing code, whereas someone working on a new GNOME application might not expect to have to do that kind of thing just to get basic functionality like 'reappear at some position and size as last time' working.

The Metacity devs are showing exactly the kind of attitude that hundred papercuts is supposed to work around. And so are you. This bug is NOT a duplicate, as it wasn't filed against Metacity, and it's not filed against Compiz either, although they both have the same problem - it's a usability bugfix apparently required by all the window managers/desktop environments. Where should it be filed if not against 100 papercuts?

Do you care more about making Ubuntu better, or about closing bugs? Because this one has not been fixed, by anyone, and it does need to be.

Denny de la Haye (dennymeta) wrote :

Also added to the GNOME Usability bugzilla, here:

description: updated
Vish (vish) wrote :

@Denny de la Haye:
I do appreciate your efforts in trying to improve Ubuntu,
We all want to improve Ubuntu

BUT Kindly Understand what the papercuts projects is about:
Paper cuts are _trivially_ fixable usability bugs that the average user would encounter during his/her first day of using vanilla Ubuntu 9.10.

What you are requesting is not a trivial fix... Though the outcome is a trivial enhancement , it needs to be looked into in detail.. Hence it was the reason for closing the papercut part as invalid...

You CAN assign the bug to the other projects. Which can look into the bug
Kindly reassign the bug to the projects which need to look into this.

I had already tested the behavior of the apps.
But my comments regarding the apps you have reported are:

The present behavior is ideal that the app appear in the centre, is essential for:
* Passwords and Encryption Keys
* Take Screenshot
* Disk Usage Analyser
* Remote Desktop Viewer

Positions Should NOT be remembered, [since several instances of the apps are often open a fixed location is NOT ideal ]
* Terminal
* Text Editor

Evolution and firefox did remember the position for me, So i'm not able to replicate it then , tried again now also , but it remembers the last position.

I had not tried Character Map previosuly> But can confirm that it does not remember the last opened state.
Havent tested gFTP.

You can assign it to the different programs you feel are not remembering the the last open state...

Again to remind you the "invalid" is ONLY for the papercuts... you CAN assign to other packages.

Denny de la Haye (dennymeta) wrote :

Could you suggest a suitable place to assign it? There doesn't seem to be a general Ubuntu 'desktop usability' project that I could find with Google. We already know Metacity will close it as 'not their problem', and I assume Compiz would do the same. Not sure where else it could/should go...

I was hoping it would be fairly trivial to fix in that Devil's Pie could be used to implement some of the solution, but perhaps that's still not trivial enough. This is definitely something that someone new to Ubuntu would find to be a usability failure - my reason for filing this bug in the first place was that a friend tried Ubuntu last week and went back to Windows after three days due to this specific issue - he found it that annoying, just a total show-stopper for him that application windows and dialogues didn't always appear in the same place that he'd put them last time. I'm sure that seems silly to many people, but I can appreciate his point - it's been annoying me for years too, although not enough to stop using Linux/GNOME.

Denny, I will assign the duplicate bug to project Ayatana. We are collecting usability issues there that should be addressed, but are too large to be part of hundredpapercuts.

mac_v (and others) are correct, this is a very large problem affecting multiple applications, toolkits, and display components.

Denny de la Haye (dennymeta) wrote :

Okay, thanks.

Once again, I don't think this is a duplicate, in that it affects multiple toolkits (etc) as you say, not just Metacity which was what the first bug focused on and was closed because of.

James Lewis (james-fsck) wrote :

This may not be entirely within the window manager space, some involvement with the toolkit may be required too... I do believe this is a genuine problem, and by "passing the buck" and saying that it is simply the applications issue, you are making yourself part of the problem as described by Denny.

The window manager currently has a set of placement algorithms which put windows in logical places on screen... however, Windows has solved this problem with a solution which works very well (better??) in a specific set of circumstances... I would not like to see every window automatically placed where it was before, but it would be a great option to have for certain classes of window (possibly needs an extra flag from the app via the toolkit?)..

For example, within an application, opening a particular dialog repeatedly, you would want the window to be placed the same way each time... certain apps might do well to be restored to wherever they were when they were last used...

I really believe that this is NOT wholly the responsibility of the app, or any individual layer... but it would be good to have a framework for the app to specify how placement of a window should be handled, to allow this kind of functionality to become standard.

Vish (vish) wrote :

@ James Lewis:
No one has "passed the buck" here... This bug was rejected from papercuts project ONLY

 A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10. A paper cut should be a small usability issue that affects many people and is quick and easy to fix.

 For further info about papercuts criteria , pls read >

This bug is very much alive and requires a lot of attention, hence David Siegel has assigned it to Ayatana Project.

Denny de la Haye (dennymeta) wrote :

Metacity seem to have started work on a fix for this, not sure if that will benefit other GNOME WMs as well:

Bug is being moved...

tags: added: ayatana
Changed in ayatana:
status: New → Invalid
James Lewis (james-fsck) wrote :

As a interested party, I would have to say that having provocative status changes such as ->invalid should really be accompanied by some kind of explanation.

Bug is being moved [to another project].

The Ayatana project is being renamed from "ayatana-project" to
"ayatana" for some reason, so the bug was invalidated in the old
Ayatana project. I've tagged the bug "ayatana" to avoid losing track
of it.

Vish (vish) wrote :

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

Changed in hundredpapercuts:
status: Invalid → Won't Fix
erlguta (gonzalomarcote) wrote :

Is unacceptable that gnome does not have this option in 2010.

Launchpad Janitor (janitor) wrote :


Changed in ubuntu:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.