Remember the main window size between runs

[raman78]

What & why

The main window opens at a fixed 1280x720 on every launch, however it was left. This stores its size and maximized state in the settings file and hands them to the viewport builder on the next start.

This was originally part of #6; that PR has been narrowed down to the overlay itself.

What is in it

• Settings gains a window section (size, maximized). It is #[serde(default)], so settings files written by earlier versions keep loading — covered by a test.
• The size is tracked in App and written once it has been stable for two seconds, so dragging a window edge does not rewrite the settings file every frame. on_exit flushes a change that has not settled yet.
• While the size keeps changing, the window is being dragged, so a repaint is requested every frame. Previously the contents trailed behind the drag.
• The minimum window size goes from 480x270 to 800x600. At the old minimum the toolbar wraps into several rows and the tabs below it have almost no room left. This is the last commit and easy to drop if you would rather keep the old minimum.

Two details worth flagging

The size is read from ctx.viewport_rect(), not from ViewportInfo::inner_rect. inner_rect is built from window.inner_position(), which returns Err on Wayland, so the whole rect is None there and nothing would ever be recorded. The viewport rect comes from the surface size and behaves the same on both backends.

It is scaled by ctx.zoom_factor(). The viewport rect is in egui points while with_inner_size takes logical pixels, and the two differ by exactly the zoom factor that the "ui scale" setting drives. Without that scaling, a ui scale of 1.5 would shrink the window a little on every launch.

Why the position is not stored

Wayland gives a client no way to read or set its own top-level position: winit returns Err(NotSupportedError) from outer_position(), and set_outer_position() is an empty function there. Persisting it would restore the window on X11, Windows and macOS and silently do nothing on Wayland. Size and maximized state are the part that behaves identically everywhere, so that is all this stores — there is no cfg anywhere in the change.

eframe already clamps the requested size to the largest monitor, so a size carried over from a larger screen still comes up usable.

Testing

Verified on KDE/Wayland: the size and maximized state survive a restart, including when the process is killed without a clean exit, which the deferred write covers. Not tested on X11, Windows or macOS.

Overlap with #6

Both this PR and #6 change the same lines of src/app/mod.rs and src/main.rs — #6 removes the window-geometry code that used to sit there, this one adds its own version in the same place — so whichever of the two you merge first, the other will report a conflict.

Nothing for you to resolve: merge either one in any order and I will rebase the other branch and push, which updates its PR automatically. The two changes are independent in substance; only the text overlaps.