Opinions on restoring positions and sizes of windows automatically

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

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.

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.

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:

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?

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.

This is great news! I didn’t know that there already is an API for that. I tested it and it seems to work reliable on X11 as well as on Wayland. So I think it’s a proper solution to the issue. I will happily add that to Nautilus, if the maintainers are open to that.

@arnaudb

Didn’t realize the info was already there. Thanks for sharing.

I’m going to go ahead and steal that now…

@johrpan

That would certainly get a thumbs up from me. (Not that my opinion actually matters that much, but still)

Here is the MR.

That might not get accepted due to GDK_WINDOW_STATE_TILED being deprecated since 3.22.

I know that and if that’s the case I’ll just change it to check all separate states. But as it’s still included in Gtk 4 (as GDK_SURFACE_STATE_TILED) and not marked as deprecated there, I thought it might be ok and cleaner.

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.

I agree with the general statement as such. In my own ruby-gtk applications, I added code to
just do .move(0, 0), for top-left positioning. The reason for this is mostly because that way I
can have a “base” to start with; the main window appears on the top left, and from there
I can reposition, resize and so forth. But even that, of course, may not be what every user
wants to have; it’s hard to want to have a certain standard whenever a standard conflicts
with a user’s preference.

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.

I think it will all depend on the user at hand. What is fine for some users may not be great
for other users. Age also plays a role; as my own eye sight gets worse, I much prefer larger
fonts for example, which do not look as “slick” as smaller fonts (since you can pack more
information into smaller fonts, for any given monitor space). Personally I try to go with
“optimize workflow speed” rather than “optimize pretty looks”, so what I do is more
catered towards trying to get the things done that I want them to be done, without much
additional fuzz. So I don’t think I am necessarily the main target audience - a lot of what
I do I do via a scripted way, mostly through ruby. So the GUIs are sort of mostly just
“helpers”, and I try to write as little GUI code as possible, while abstracting as much as
possible.

Adding CSS support was a good idea, IMO. I can, sort of, use a “unified” approach, to
some extent, for styling GUIs - both on the classical desktop but also for web-applications.

I also think remembering the last position is more a feature than an anti-feature by the
way, so I concur mostly with johrpan BUT not 100% either. It really depends, IMO.

Hello developers,

I created a report for nautilus and now the report was closed.

I as a user miss a system wide function for all programs of Gnome to reset the default size and position.

In my report I also suggested an idea how it could look like and why I need this function.

https://gitlab.gnome.org/GNOME/nautilus/-/issues/1704

What is special about the default size of the window that you want to reset it?

For example, terminals are often have a reset to 80x24 characters for historical reasons, but I don’t see what is special about the default size of the Nautilus window?

I wrote this in report. Reposted here again:

My window sizes and positions are a mess and I haven’t found a quick and easy way to reset the windows so that the next time I open the program, they look like I opened them the first time.

I am actually talking about every window I have opened in Fedora 33 (Gnome). There is unfortunately no system wide function for all programs in Gnome.

I imagine it like this. I open Gnome Preferences and select the programs where I can decide whether to reset the window size only or reset window size and position.

I understand what you’re asking, I’m just wondering why you want it.

What is special about the default window size and position? Why is it useful to be able to reset them?

For me mainly because of the mess. Sometimes also for design reasons, because is calmer with default size and position, I know that the program can restore exactly how I started it for the first time. It also shows that nothing is impossible for people.

Oh hell no. Let’s please not regress to the dark ages of applications not remembering their states, especially their sizes. I’ve been there, it was hell. I spent a decade filing individual bug reports on every application under the sun to request that they remember their sizes and states (and position, which I am sad to learn here isn’t supported under Wayland?) so that I don’t have to waste my time resizing them back to the desired size everytime I launch them.

If the venerable GNOME 2 HIG documents hadn’t disappeared from the net, I’m pretty sure I could cite a detailed section on why remembering spatial attributes like window sizes is a good thing from a usability perspective. Not everybody runs their applications fullscreen or as a 640x480 utility window.

If your issue is about not wanting to remember the size when a window is tiled (but still remembering the size from when the window was not tiled or maximized), then that’s somewhat more specific and debatable, but even then I would argue that not saving the size when tiled would work against your goals. Other than that, I can’t imagine (let alone see an empirically-backed reason) why you would want an app not to remember its window size.

You talk about a “mess” and wanting something “calmer”; well, I feel very much the opposite from you about this, and I think many users silently feel the same way as me and @Dies; to me, a “mess” is seeing applications behave as if they had a lobotomy or brainwash after every use, making me question how much attention was paid to user experience detail or how safe my data is if it can’t even bother to remember its window sizes. It is the opposite of “calm”. I don’t come back to my computer expecting attributes reset everytime I use it, I come back to my computer expecting it to remember what my preferences are and what my workflow looks like, I want it to facilitate a state of flow and let me jump right back into productive work. “Everything in its place, just as I left it” is applied zen. That is calm.

By not remembering window sizes you are subjecting me to whatever potentially ill-defined size is the default, then needing to resize the app on every launch. This is Sh** Work, and I shouldn’t have to do it. I only resize when I change my workspace layout.

I am voicing my opinion here just so that it is clear there are users who very much want the current behavior to exist and would consider the proposal at hand to be a regression in usability.

Yeah, this is my least favorite part of Wayland…

The first application tends to open in the center of the screen, which is fine. But everything after that seems to open at top left, and yes on top of each other if you open several applications at one time.

Worse yet, some applications are starting to just open maximized or close to it everytime.

Huge regression to say the least.

Your comment prompted me to search for this now, and in addition to Wayland not allowing apps to position themselves (found this bug report in mutter) I have found the bug report regarding the maddening de-centering of application windows under the Wayland-based session (and my comment there tries to give some historical perspective on the matter).