Egui persistence test

[hml-pip]

This feature will create data\app.ron file in storage_dir.

1: 1920x1200

2: 1920x1080

It doesn't retain the previous window size when exiting in fullscreen mode, and when you exit application while in fullscreen on monitor 1, it restores to 2 at next startup on Windows, if there's other issues on other platform, I'll port the code from iced version.

[ggand0]

I tested it and window size was indeed not restoring. Two things were overriding eframe's restore:

1. The hardcoded with_inner_size([1280.0, 720.0]) in main.rs always sets the window size before loading the persisted state app.ron (points to a Rusty Object Notation file)
2. There's existing code (src/app.rs:451) that corrects window size in physical pixels on the first frame for DPI-scaled displays, since egui only offers API for logical pixels. That part was firing unconditionally so I gated it to only do it for the initial app launch

The fix I pushed should now restore window size as well as positions, and I verified it working on macOS and Ubuntu. Can you verify it works on your Windows?

[hml-pip]

Windows was already working as "intended" (It restore size and position correctly in window mode, but doesn't have the features we implemented for the iced version) before your commit, it seems Windows wasn't affect by your forced .with_inner_size([1280.0, 720.0]), the issues I mentioned still presents.

I think my requirements are edge cases. I'll see what I can do after completing the compressed file support and slider preview with possible additional PR if you want to merge this one.

[YelovSK]

I was also trying the window persistence, but it has some annoying bugs, at least on Windows.

The first one is that when restoring a maximized window, it briefly flashes white. I'm pretty sure that's an issue in winit, I made a PR here - rust-windowing/winit#4575. Basically, when the app is launched initially with the hidden and maximized state, winit first calls winapi's maximize API, which briefly shows the window, and then immediately hides it.

The second one is that the normal window size is not persisted when maximized in egui. So when you unmaximize the window, it doesn't get restored to the previous size. Winit doesn't have an API that would return the normal window size, so I could only fix it by calling winapi in egui, and even that has some potentially sketchy cross-coordinate stuff, so I ignored it.
However, related to this, I personally also have an issue where the maximized window gets opened on the wrong monitor, so I made a PR for that in emilk/egui#8191 so that it chooses the monitor by overlap instead.

Right now, the maximized window persistence on Windows is really annoying.

[hml-pip]

Does the iced version work for you?
I've tried to cover most situations.

[YelovSK]

Does the iced version work for you? I've tried to cover most situations.

The iced version is a bit less broken, but also acts weird when restoring the window. See video.

Recording.2026-05-24.122318_1.mp4.mp4

But I am using the egui version, since it feels a bit better to me.

[hml-pip]

I'd say it's not perfect, but it gets the job done.

The reason I'm asking is that, at worst, I can port the code made for the Iced version, but I'm not sure the added code complexity is worth it. Even then, the outcome might not satisfy your expectations.

[YelovSK]

Oh, I don't have a strong opinion. Of course, ideally, the egui persistence would work perfectly, but that isn't the case.

I already tried doing it directly in viewskater, and it was mostly passable, including getting rid of the white flash (iirc I created the window hidden, and maximized it a bit later, but that showed the maximizing animation), but it was a bit too.. I wasn't comfortable with that being the final implementation. I only got it working well with the winit and egui patches, but I have no idea if those will get merged. Well, except for the unmaximized size. I imagine it's possible without using the winapi by persisting the last window size when not maximized/minimized.

[hml-pip]

Check my new implementation and see if that works for you, I think this PR might not be needed if there's no upstream changes.

[YelovSK]

Check my new implementation and see if that works for you, I think this PR might not be needed if there's no upstream changes.

Seems to work fine, except for the white flash and the unmaximize not remembering the size. This PR emilk/egui#8191 was just merged in egui, so in theory, the egui persistence should work almost the same as your implementation, with the only difference being that, in your PR, unmaximize restores a smaller window, and in egui's persistence, it restores the maximized size.

If the winit fix gets merged, I think it should fix the white flash in both your implementation and in the egui persistence.

[hml-pip]

Thanks! I found another problem: when you set the scaling to anything other than 100% for a high-resolution monitor on Windows, maximized or full-screen window does not recover properly on the next startup in my implementation, I'll keep digging.

[ggand0]

Ok I reproduced these issues on Windows 10 dual monitor setup:

1. White flash on maximize restore
2. Original window size lost when leaving maximized/fullscreen -
   eframe doesn't save the window size before maximize at all (ref: Incorrect maximize behaviour emilk/egui#3494)
3. Wrong-monitor restore -
   maximized/fullscreen/windowed on secondary monitor, quit, relaunch -> comes back on primary

For 1, @YelovSK opened rust-windowing/winit#4575 but winit tends to be slow on PRs so probably not getting merged soon. For 3, @YelovSK's emilk/egui#8191 was merged, but we're pinned to egui 0.31 and it's not available yet.

Given these, I think implementing custom persistence (PR #29's direction) is the right approach.

[hml-pip]

I think updating to egui 0.35 is a chore and a lot of works to even get it to compile. This needs a separate PR to do if that's the direction we're heading.

Incomplete summaries

Replace App::update with fn logic and fn ui

More ui less context

improved-popups-tooltips-and-menus

Some deprecations are easy, but others need additional testing.