[zorr]

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.