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