Opinions on restoring positions and sizes of windows automatically

Desktop
7

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 :wink:

8

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?

9

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.

10

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
11

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
12

Replying as a developer who saves and restores its applications size. :smiley:

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
13

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
14

I opened a Nautilus issue for now. I think, Nautilus would really benefit from dropping this behavior.

15

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. :smile:

1 Like
16

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
 :smiley:

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).

17

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.

18

Evince stores those settings in the file’s metadata. You can try:

$ gio info [some-file.pdf] | grep evince

1 Like
19

Users around me love this as default behavior. (Even for Nautilus.) =) So it’s better to deviate from it only when there a reason.

20

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.

21

It seems like there really is a big-enough audience for that feature. And I also don’t dislike it in general. Just the annoying complications with edge-tiling etc. But as I have learned, there is nothing the applications themselves can do about that. Maybe, in the long run, there’s a place for some sort of protocol-based solution.

1 Like
22

Evince does not change the files. Those attributes are stored in the files metadata using GIO. As a matter of fact, if you do files operations with gio, such as gio rename or gio move the metadata will be ok. If you move the files using mv, the metadata is gone.

23

I could see it being an annoyance in that specific situation.

I don’t know that anyone would want to add code for that but you could check if the dimensions suggest the window is tiled and not save if that’s the case.

i.e. does the width match half screen width and is height within 50 pixels of screen height? Then don’t save the size. But that seems like kind of a hack that would probably fall on its face at times.

24

I do it in every application I maintain. It works great and is not difficult to add, at least in non-verbose languages. Just needs someone to write the code. :smiley:

25

Well, that and someone to agree to merge it


But more importantly, are you running into any cases where it doesn’t work right?
And what’s the actual logic you’re using to detect these edge cases?

26

Sorry, rereading your initial comment: I’m not guessing based on the window size, I’m just using the window state, so there’s no uncertainty. In LightsOff (that I don’t maintain), Gtk3 and Gtk4.