Persist window geometry and state - #906
Conversation
|
I'm having a bit of trouble understanding the pieces here, it seems like there is some duplication:
What is going on with all the retries and pending stuff? Can you walk me through the sequence here? What is the downside of waiting for the window to show and then doing it?
What is |
My apologies, I was trying to quickly get a proof of concept working and missed this. I've now removed redundant macOSZoomed, and just rely on macOSMaximized. This should be handled.
Another mistake, I've used
I originally had the same, and added a new org field, would this be the correct way to go? add default
I've really been trying to fix things without needing too much complexity, but sadly it's been difficult, specifically dealing with loading into a fullscreen maximized "Space" on macOS, or handling apps with custom titlebar/windowing styling like fizzy has. SDL's events for entering and exiting these states are not reliable enough to do things like correctly update the app behind/underneath the titlebar traffic light buttons as the bar appears and disappears etc. I'd recommend comparing current fizzy native editor with a current base DVUI app to see the differences in smoothness entering and exiting maximized states.
This is something I wanted to ask you probably a better way to handle, but for fizzy specifically, I needed some way of triggering SDL specific window styling code before each |
|
Thanks, I totally understand going fast. Thanks for adding the org thing. I'm digging into this - the first thing I tried to do was understand the |
|
@foxnne I pushed a commit trying to verify to myself what parts are needed for geometry saving. I am NOT giving up on rendering during the transitions, but I don't yet know if that can be done inside dvui, or is too complicated and we need to find the right api to allow fizzy to integrate that. One thing for example - I added a global Also I don't think I've even gotten to just the geometry saving part yet, just got to a reasonable checkpoint. |
|
I think I'm agreeing with you, and I'm going to try to simplify this, probably at the expense of being able to load back into a fullscreen state. Upon thinking about it, I think thats where I was struggling the most, and I think it's honestly not something to try to support currently. I apologize for the complexity of this, I'll try to ping you when I get this in a more reviewable state. |
|
I think I'm close to having a decent split between dvui persisting the geometry but fizzy still doing the animating during resize. I will push a bit more and report where I got. |
|
I hope I didn't step on your toes! I just pushed a commit that removes a lot of the complexity added by trying to load into a fullscreen space seamlessly. This now should just instead load into the last non-maximized size, and I think that's probably the true desired behavior for windows, though the hook exists for apps that want to handle things themselves. |
|
Okay, I've also made a change to how/when window geometry is saved. Before, it was just saved on a successful app close in
In this state and I'm sure plenty of others, the smaller pre-maximized state is never saved. Instead, I've opted to track the geometry as dirty when events change it, and save the zon file on the first non-resize/move event such that hopefully we don't miss any window sizes but also avoid trying to write to disk during a resize. |
|
@david-vanderson Okay, I think I'm a bit happier with where this is now. Please let me know of any other areas you feel could be simplified or removed if needed. With this current code, the dvui sdl3-app example seems to behave as expected, other than a small quirk with opening the app after it was closed at screen-size, but not "maximized" (in its own Space in macOS): The window doesn't seem to reopen full sized, but slightly smaller horizontally. I couldn't find any reason this is happening in our code, and seems to be a quirk with opening a full size window on macOS without it being "maximized"? |
Do you mean slightly smaller vertically? I saw something like that with fizzy but not with the sdl3-app, where restarting from a maximized (not fullscreen) would make the window be shorter and lower than expected by about the height of the window titlebar.
I think sdl3-app is working for this scenario? But a double-check would be appreciated, maybe I'm not understanding how to reproduce it? I'm still working on how fizzy should interact to be able to override this stuff. |
Yes, but this is fizzy-specific, for the titlebar issue. But with the regular sdl3-app, I if I close a maximized (not fullscreen) window and reopen it, its slightly smaller horizontally (maybe about 10 px?). I can't seem to reproduce the horizontal issue with fizzy, but it makes sense fizzy has a titlebar spacing issue since fizzy sometimes hides and sometimes shows the titlebar spacing.
Was this before? because my recent push fixed this. Current behavior for me works both with sdl3-app and fizzy for all scenarios, save for the strange slightly smaller window on restore from maximized, which I'm okay with. |
That is weird and I haven't been able to see it (with either sdl3-app or fizzy), but I'll keep an eye out. |
|
I'm happy with the behavior of everything as is now, I think all that I see left is removing debug logs, but I'll leave this up to you and please let me know if you'd prefer i make any further changes |
|
Oh I thought I had removed |
|
I'm happy now with how it works on sdl3-app. But I'm not sure we've solved it for fizzy. I pushed fizzyedit/fizzy#184 for how I'm trying to run it with this branch. Can you test that and tell me what you see? Two things are confusing to me:
Any ideas here? |
I see the same things, but no worries, I'm working on another branch with other changes, and I am up to date with what you have here and I can make any of this work for me :) thank you for the changes you made here that unblock me, and add this functionality. |
This catches a problem on Linux x11: * load maximized * click window to return from maximized * close and reopen * window is maximized When returning from maximized trackGeometry still sees the window as "maximized". So call trackGeometry in deinit just before saving the information.
|
Good. I'm very happy with this. Especially nice when I am iterating on something that requires a certain window size. I'm sure we'll need some more tweaks for this, but this is a great step in the right direction. Thank you! |
|
Thank you for this! |
Persist window geometry and state
2 participants
Hey!
We recently talked about this a bit, and this is a hopefully working proof of concept that works both with the current version of fizzy and also generic DVUI apps. Currently only supports SDL3.
To test:
zig build sdl3-app, change window size or maximize, and then close windowzig build sdl3-appagain and hopefully observe window return to previous size/position/stateI have only currently tested this on macOS, which needed some additional code to get apps to restore into exclusive fullscreen Spaces vs just window-sized-maximized.
I'm sure we will need some changes here but hopefully this is a decent start.
Notes:
window_geometry.zonfile, which defaults to sdl's preference path subdirectoried into the app's title. An override was provided as well, so apps can have the window geometry file saved with their app's other settings/prefs files if wanted in another location.