The window state is not the GTK devs problem but an app developer problem. One of the very first topics in the GNOME developer guide is how to use settings to save/restore window state on close/startup.
The window state is absolutely, partly GTK's problem, or at the very least _not_ the developer's problem. Storing window size yourself opens a whole can of worms, including but not limited to:
- Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
- Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
- Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
It is an OS/DE's responsibility to give me windows. I'll put whatever the hell I want in there, and it's my job to save that content, but pretending that saving window state is the job of the app is some peak clown shit. On a scale of how bad of a UI toolkit this puts you, you are now at "Win32". Congrats Gtk4.
I explained in other siblings already why the toolkit cannot make assumptions about storing and restoring the window size. The app knows about the content and requests one or more windows with a requested size depending on its contents, and it's the OS/DE/WM that has to place it somewhere.
> - Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
The link I provided documents this exact process in 4 languages including C and JavaScript and all the saving/loading/parsing and even binding the managed settings to the properties of a window is handled for you by the toolkit. It is 1 function call to initialize the settings and 1 function call per setting to bind it to the window property you want to manage. Oh, and these settings can be configured externally with various tools or GUI's as well if you want to.
> - Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
AFAIK this is not something the app developer has to do and is handled by the DE with maybe a little help from the toolkit.
> - Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
Nope, an app can only request windows with some requested size, and it's up to the DE/WM to place it. Take tiling window managers for example which might be configured to always open new application bottom right, or top left, or floating or whatever. Sure, an app might dig down into the lower levels to finetune behavior but then the app developer chooses to open this can of worms to make sure it still works with all flavors of DE's/WM's/X11/wayland/etc
> You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
GTK already has these dependencies and abstracts them for you in higher level API's while still providing access to lower level API's if you choose to use them. (Gdk for displays, Gio for IO and parsing/saving/loading and binding to settings is in Gio as well). Client side decorations is a matter of choosing what base window type you use, so you can have default decorations or start with a blank slate.
I honestly don't know what you expect GTK to do more than it already does.
It has some logic to it though: An application developer is going to use the toolkit to open one or more windows on startup and the DE/WM has to place those somewhere. The first window opened by the app is not guaranteed to be the main window and it's not guaranteed to always be the same window (sometimes it can immediately open the main app window but other times it might have to show a smaller login window first, or immediately open multiple windows, etc).
- It is the responsibility of the application developer to determine for each window what size it should be depending on the content in the window which can be dynamic. It's also not a fixed thing, but more a hint to the DE. The relevant GTK method is called gtk_widget_set_size_request(width, height) with the focus on "request" (defined in widget but window inherits it). Saving/restoring window state is left to the developer because of the dynamic nature of windows as explained above.
- It is the responsibility of the toolkit to make sure the window gets created and then communicate the requested size to the DE so it can be placed on the screen.
- It is the responsibility of the DE/WM to place this window where the user expects it and depending on the type of DE/WM it might have different behavior. For example a tiling window manager might be configured to always open new windows in the bottom right, or top left, or have config overrides for specific applications to always open floating or maximized.
So yes, the size is the apps problem (because it knows what content is on a specific window and might know about the previous window size from last time), and the position is the DE's responsibility because that can depend on user configuration and the specific DE/WM used. The app cannot make any assumptions about that. It can only request windows with a specific size.
As explained in a sibling comment, the toolkit cannot make assumptions about restoring an apps window state to its previous size. Sure it might work for simple hello world apps that always open the main window, but that's not always the case. Sometimes applications have to open a different window or multiple windows on app startup. The only thing the toolkit can reliably do is translate the requested window size when an application opens a window to the DE so that the DE/WM can place it on the screen.
Because of the dynamic nature of opening windows, app developers should have control over storing/restoring the window size. Simple apps might always store the last window size and restore that exact size on startup. Other apps might have to run some logic first before they know how large the window should be, and then request the toolkit to create a window of that size.
ohgodplsno|2 years ago
- Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
- Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
- Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
It is an OS/DE's responsibility to give me windows. I'll put whatever the hell I want in there, and it's my job to save that content, but pretending that saving window state is the job of the app is some peak clown shit. On a scale of how bad of a UI toolkit this puts you, you are now at "Win32". Congrats Gtk4.
zorr|2 years ago
> - Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
The link I provided documents this exact process in 4 languages including C and JavaScript and all the saving/loading/parsing and even binding the managed settings to the properties of a window is handled for you by the toolkit. It is 1 function call to initialize the settings and 1 function call per setting to bind it to the window property you want to manage. Oh, and these settings can be configured externally with various tools or GUI's as well if you want to.
> - Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
AFAIK this is not something the app developer has to do and is handled by the DE with maybe a little help from the toolkit.
> - Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
Nope, an app can only request windows with some requested size, and it's up to the DE/WM to place it. Take tiling window managers for example which might be configured to always open new application bottom right, or top left, or floating or whatever. Sure, an app might dig down into the lower levels to finetune behavior but then the app developer chooses to open this can of worms to make sure it still works with all flavors of DE's/WM's/X11/wayland/etc
> You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
GTK already has these dependencies and abstracts them for you in higher level API's while still providing access to lower level API's if you choose to use them. (Gdk for displays, Gio for IO and parsing/saving/loading and binding to settings is in Gio as well). Client side decorations is a matter of choosing what base window type you use, so you can have default decorations or start with a blank slate.
I honestly don't know what you expect GTK to do more than it already does.
phkahler|2 years ago
"The position of the window is best left to the window manager."
Why TF they think size is the apps problem but location is the WM problem is beyond me.
zorr|2 years ago
- It is the responsibility of the application developer to determine for each window what size it should be depending on the content in the window which can be dynamic. It's also not a fixed thing, but more a hint to the DE. The relevant GTK method is called gtk_widget_set_size_request(width, height) with the focus on "request" (defined in widget but window inherits it). Saving/restoring window state is left to the developer because of the dynamic nature of windows as explained above.
- It is the responsibility of the toolkit to make sure the window gets created and then communicate the requested size to the DE so it can be placed on the screen.
- It is the responsibility of the DE/WM to place this window where the user expects it and depending on the type of DE/WM it might have different behavior. For example a tiling window manager might be configured to always open new windows in the bottom right, or top left, or have config overrides for specific applications to always open floating or maximized.
So yes, the size is the apps problem (because it knows what content is on a specific window and might know about the previous window size from last time), and the position is the DE's responsibility because that can depend on user configuration and the specific DE/WM used. The app cannot make any assumptions about that. It can only request windows with a specific size.
phkahler|2 years ago
zorr|2 years ago
Because of the dynamic nature of opening windows, app developers should have control over storing/restoring the window size. Simple apps might always store the last window size and restore that exact size on startup. Other apps might have to run some logic first before they know how large the window should be, and then request the toolkit to create a window of that size.