Skip to content

Save and restore the dock's display state from persistent storage#422

Merged
kevinaboos merged 81 commits intoproject-robius:mainfrom
alanpoon:save_ui_persistent#414
Jun 25, 2025
Merged

Save and restore the dock's display state from persistent storage#422
kevinaboos merged 81 commits intoproject-robius:mainfrom
alanpoon:save_ui_persistent#414

Conversation

@alanpoon
Copy link
Contributor

@alanpoon alanpoon commented Mar 5, 2025

Fixes #414

Screen.Recording.2025-03-12.at.1.21.32.PM.mov
  • Save the layout when the Desktop UI view is being hidden, e.g., due to a resize event. (Save the UI layout when transitioning from Desktop --> Mobile layout #251)
  • Preserve the proportional size of each pane in the dock.
    If the user has resized a dock pane by dragging the splitter, that is currently not preserved.
  • When the user closes/exits the Robrix app, we should save the layout to the persistent settings on disk. Then, we can restore that saved layout automatically upon the next time the user re-opens Robrix.
    This can also be offered as a preference/setting in the settings pane, once that is implement.
  • [] Future Save the layout on demand (a future feature), such that the user can store a list of "favorite" layouts that they can easily switch between, on demand.

I have also explored saving and restoring the window dimension. Currently makepad does not have a solution resize the window dynamically.

@alanpoon alanpoon marked this pull request as ready for review March 12, 2025 05:28
@alanpoon alanpoon added the waiting-on-review This issue is waiting to be reviewed label Mar 12, 2025
@kevinaboos kevinaboos added waiting-on-author This issue is waiting on the original author for a response and removed waiting-on-review This issue is waiting to be reviewed labels Mar 12, 2025
@alanpoon alanpoon added waiting-on-review This issue is waiting to be reviewed and removed waiting-on-author This issue is waiting on the original author for a response labels Mar 14, 2025
Copy link
Member

@kevinaboos kevinaboos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few nits about naming clarity:

  • The word "prompt" should be something like "notice" instead, since a prompt implies that we're asking the user to input some info. But really, we're just showing the user a notice that something is happening in the background.
  • Similarly, the word "timeout" should be replaced with "failure"/"failed"/"error", since timing out is just one potential error that could occur when loading a room.

See my other comments about how to potentially redesign the action handling logic for Pending, Success, and Timeout.

@kevinaboos kevinaboos added waiting-on-author This issue is waiting on the original author for a response and removed waiting-on-review This issue is waiting to be reviewed labels Mar 20, 2025
@alanpoon alanpoon added waiting-on-review This issue is waiting to be reviewed and removed waiting-on-author This issue is waiting on the original author for a response labels Mar 27, 2025
@kevinaboos
Copy link
Member

Waiting for Makepad to merge in api requirement for persistent storage and restoration of window_state makepad/makepad#770

It's been merged now.

Copy link
Member

@kevinaboos kevinaboos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the Makepad contribution, this PR is nearly ready. I just left a few very minor comments.

Copy link
Member

@kevinaboos kevinaboos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've cleaned up this PR and the code is now ready to go, so please pull down the latest changes onto your computer.

Currently, there is still an issue with InviteScreens: they are not being drawn properly after they get restored. See the screenshot below:

image

This is because you need to add the same logic used in the RoomScreen to the InviteScreen too. Things like checking whether the room is_loaded, then calling set_displayed_invite() when it becomes loaded, etc. It also needs the same restore_status_label.

@kevinaboos
Copy link
Member

I've also noticed that the window position is not always respected by macOS, but the window size is used properly. Nothing we can do there, as it seems to be an OS-enforced behavior.

@alanpoon
Copy link
Contributor Author

I've cleaned up this PR and the code is now ready to go, so please pull down the latest changes onto your computer.

Currently, there is still an issue with InviteScreens: they are not being drawn properly after they get restored. See the screenshot below:

image This is because you need to add the same logic used in the RoomScreen to the InviteScreen too. Things like checking whether the room is_loaded, then calling `set_displayed_invite()` when it becomes loaded, etc. It also needs the same `restore_status_label`.

Fixed.

@kevinaboos
Copy link
Member

kevinaboos commented Jun 25, 2025

Friendly reminder to actually test your code before requesting a review. Looks like you forgot to clear the restore_status_label in the InviteScreen once it has been restored. It also needs to be outside of the inner view that holds the inviter_avatar and inviter_name, otherwise it causes alignment issues even when empty.

image

I've fixed it now.

There were also several unnecessary clone()s introduced, one of which was expensive (the InviteDetails). Try to avoid those wherever possible.

kevinaboos
kevinaboos previously approved these changes Jun 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tracking issue for dock save/restore improvements

3 participants