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