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

[alanpoon]

Fixes #414

https://github.com/user-attachments/assets/5777e25a-200e-4b57-ac6c-8b03240e5146

• [X] Save the layout when the Desktop UI view is being hidden, e.g., due to a resize event. (https://github.com/project-robius/robrix/issues/251)
• [X] 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.
• [X] 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]

2. What happens when a user closes a RoomScreen while the room is still Pending, but before the Failure or Success action occurs? Let's ensure that we are handling that scenario properly.

What is expected behavior for item 2? Failure/ Success action will still be posted, but there is no room screen left to handle them. So nothing happens

[kevinaboos]

2. What happens when a user closes a RoomScreen while the room is still Pending, but before the Failure or Success action occurs? Let's ensure that we are handling that scenario properly.

What is expected behavior for item 2? Failure/ Success action will still be posted, but there is no room screen left to handle them. So nothing happens

Right, that's correct. I just wanted to ensure we were considering that scenario, and that there weren't any threads or conditions that would be waiting on that room to be loaded.

That was more of a concern with your previous design that had a DOCK_WAITING_ROOMS list, in which you would need to remove a closed room from that list (which I think was missing).

[kevinaboos]

And, another more major problem, the dock itself seems to transition into an incorrect state. Take a look at the screen recording here... the dock seems to lose a lot of state after I drag the Testing2 room into a new splitter, as multiple rooms are now missing, and the dock layout is also surprisingly lost. I can confirm that this never happens in previous versions of Robrix without the features from this PR that save/restore the dock.

https://github.com/user-attachments/assets/ca5bdf9e-8de0-4e15-8dae-1d6250579cc3

[kevinaboos]

@alanpoon i apparently forgot to push a commit i made yesterday that restored the all_known_rooms_loaded boolean, sorry about that. I have just pushed it now as 0c022f7.

[kevinaboos]

@alanpoon is this blocked on https://github.com/makepad/makepad/pull/711?

[alanpoon]

@alanpoon is this blocked on makepad/makepad#711?

Yes

[alanpoon]

Waiting for this PR to enhancement to Makepad https://github.com/makepad/makepad/pull/726

[kevinaboos]

is this PR ready? I saw that the Makepad feature that was blocking this has now been merged in, and Robrix's main branch now depends on the latest dev branch of Makepad, which includes that PR. The waiting-on-review label was added but then removed, so I'm not sure what the status is.

[alanpoon]

Yes

is this PR ready? I saw that the Makepad feature that was blocking this has now been merged in, and Robrix's main branch now depends on the latest dev branch of Makepad, which includes that PR. The waiting-on-review label was added but then removed, so I'm not sure what the status is.

Yes, please.

[kevinaboos]

also, don't forget to resolve conflicts, quite a few PRs have landed latetly.

[kevinaboos]

I chatted with Rik about this, and he thinks that everything we need should actually be available in both the Shutdown event and the Startup event. Take a look at this conversation and see if there are any good solutions you can come up with here. Note that you should focus on the issue of "creating the window at the right size/position" (or setting it as soon as possible) rather than the issue of trying to save the window geom, since we already have a workaround for that by monitoring WindowGeomChanges.

[alanpoon]

Waiting for Makepad to merge in api requirement for persistent storage and restoration of window_state https://github.com/makepad/makepad/pull/770

[kevinaboos]

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

It's been merged now.

[kevinaboos]

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]

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:

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]

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.

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.