It seems to be a common practice for GNOME applications to save their window position and size when closed and restore it at the next startup. In my opinion, at least sometimes, this is undesirable. For applications that are used as common tools (e.g. Nautilus), it seems strange, that they reappear in the state, that you left them in. I sometimes use two windows side-by-side, but would prefer the default initial size most of the time. What do you think about adding a GSettings option to disable the automatic behavior?
Each application is responsible for that behaviour, at the moment, so any “GSettings option” would need to be per-application.
Additionally, knowing the position of a window is impossible on Wayland, so applications should never do that to begin with.
1 Like
That’s true. However, the size is restored on Wayland too.
I just wanted to know, if others do also consider this to be an annoyance. If so, I would prepare some MRs for the applications where I notice this behavior.
Is it that much annoying for you to be worth making a MR to every single project that does that (i.e. mostly every GNOME app) ? You’ll still probably want to move an app you just opened at the most convenient location on your workspace, depending on what you’re working on and/or why you are opening this application now. IMO it’s not worth all this hassle.
The problem is not the position (as you say, mostly the window is moved anyway), but more the size. As I described, it matters most for apps, that you often use with different sizes. And Nautilus is the best example for that as well as probably the only one, where it really annoys me. So I think I’ll just open an MR and see what happens. Thanks for your replies so far!
Unless you actually use more than two visible applications in the same time, you can just tile it by dragging it to the edges of the screen (at least that’s what I do but I wonder what else could you be doing with it).
1 Like
Yes, that’s what I do too. But if I want to use just one window, it shouldn’t be tiled. But it is, because it automatically restores its position and size. I know that’s a bit nitpicky 
This is also a pet peeve of mine, the guys at kde seem to be integrating all applications and creating an option on settings to enable/disable this behavior. That said, the way kde applications store their configs is different than GNOME, a hack using dbus and changing the .desktop file might be possible (the idea is to run a script to reset window’s size values to default whenever you launch the requested app).
Maybe create a freedesktop standart for this?
My personal opinion is, that this behavior should be dropped in the long run. As @ebassi said, storing positions doesn’t make sense anymore anyways. And window resizing should be handled only by the compositor and not by the application itself. Mutter already has an auto-maximize feature that is enabled by default and handles the cases, where you really don’t want to use the default window size.
But because there’s probably not that much interest in this, I think, that the short term solution would be to have a GSettings option. The only question is, whether that should reside at the application level or globally (e.g. under org.gnome.desktop). However, I don’t know how the policies on that would be and whether it is desirable for the steering Gnome developers to have that.
This is really a non-sequitur. An option is never a short term solution—except for the person proposing it, who is likely going to have their itch scratched after it gets merged, whereas the maintainers will have to deal with the setting on the long term. Never, ever propose a setting as a short term solution.
Additionally, as I said above, since it’s up to applications to do this at the moment, you will need a separate setting for every application, because it’s exceedingly unlikely we’ll add a key in gsettings-desktop-schemas.
In theory, the compositor should store the data for each application; and each application should receive the previous state from the compositor on startup. In practice, we don’t have a protocol for it; until that’s solved, a setting is not going to do you any good. Might as well ask applications maintainers to never store the window state to begin with.
3 Likes
Thanks for the clarification! Of course you are right about the maintenance burden.
Maybe that would be the best solution. But of course I don’t want to take away this feature from everyone, just because I myself happen to dislike it.
With “short term” I meant until there is a complete replacement in the form of a compositor-side solution or some other project-wide decision etc.
I think, I’ll decide whether to open a MR for Nautilus tomorrow.
1 Like
Replying as a developer who saves and restores its applications size. 
I could try to explain why saving windows positions could have meant something in the Windows 95 paradigm, but let’s avoid that, we don’t care anymore. So I’m just talking about the sizes and states.
First of all, let’s clarify something: these apps are not multi-windows. Imagining a correct multi-windows behavior for saving and restoring is quite hard, because you never know which one of your window has “the size usually wanted by the user” and which one has “a size given on the fly for a specific use.” Multi-windows application should probably drop this function, they cannot just get it right.
Mono-window apps at the opposite usually have a given use, and so “a size wanted by the user.” (That’s the case for all the games I maintain for example; a counter-example is the Peek screen-recording application, that wants to restore to a default size every time, because it’ll all the time be used for a different thing.) And this size depends notably on the size of the user’s screen. Because if I all the time open my game at 600×400, because it allows people on small screens to have the same behavior than other people, that will make people with 4k screens cry, as they will all the time have to set the window to a correct size for them. So yes, it makes sense to save window size and state in that case, in my opinion.
Various thinkings:
- it might be a good idea to switch the default (first-launch) window state to “maximized” in many applications, as long as they render great like that;
- the “half-maximized” states are quite hard to get right, because you do not want to save the window size then, and cannot at all restore the window state;
- it would be better that Gtk could handle that for us, or even better that the saving of the state and size be done by the compositor; but that’s not the case;
- adding settings is quite never a good idea; and adding global settings only works if the applications developers have nothing to do to have it working.
2 Likes
Many thanks for the elaborate reply. You have convinced me that mono-window applications should do something with their window states which, at the moment, can only be done by simply saving and restoring it.
Now that I think about it, I probably meant exactly what you mentioned now – i.e. multi-window applications.
2 Likes
I opened a Nautilus issue for now. I think, Nautilus would really benefit from dropping this behavior.
Doing a bit more research here: I usually never launch “viewer” applications directly, but looks like Evince (the PDF & Co. viewer) has a “default view,” where it lists the documents it is suggesting to open. I imagine that a multi-windows application like that could correctly decide to save the size and state of the window for this view, and avoid saving it when a document is displayed, as the user might want then to adapt to the given document. There’s of course to decide the behavior of what happens when two windows are opened at different sizes on this default page (disable that if possible, save only in sessions when only one such view is opened…), but that’s a negligible corner-case IMO, because no sane user would do that.
Edit: We might also discuss the saving of the size and state by document. And to discuss if browsing a folder in Nautilus is like displaying a given document. Human brain is fun, satisfying it is hard. 
1 Like
Evince does that. It doesn’t save the collection window size, but somehow manages to restore the document viewers. However, I don’t know where it stores that… 
This behavior makes some sense for documents, but I don’t think that it applies to folders. There can be lots and lots of folders including remote ones etc. Also, there are different views for the same folder and edge-tiling is a common mechanism for file manager windows (I think so).
I personally can’t stand when an application does not open at the same size.
I’ve uninstalled many an application over this.
The defaults are sometimes unusable.
If I have to adjust it everytime I open it that’s a blocker.
Evince stores those settings in the file’s metadata. You can try:
$ gio info [some-file.pdf] | grep evince
1 Like
Users around me love this as default behavior. (Even for Nautilus.) =) So it’s better to deviate from it only when there a reason.
Interesting. I wouldn’t expect my document viewer to change the files I’m opening without me confirming that. But I guess, this information is not that sensitive anyways. However, it seems like Firefox inserts the URI where you downloaded the file. In my opinion, this could be a concern. I didn’t expect that.