do we not have this already, with the restore_status_view? Or this is meant as a replacement for restore_status_view?

Either way, we should just have one widget that offers this. I do agree with your approach that it should be a separate widget (instead of duplicating it in both the InviteScreen and the RoomScreen), and that's been on our to-do list for a while, so perhaps that's why you filed this PR.

Thus, go ahead and modify the code to use your LoadingScreen everywhere instead of the restore status view within the InviteScreen & RoomScreen. Otherwise it'll be too difficult to maintain two different versions of the same thing.

EDIT: now we have another screen where this should be used too, the SpaceLobbyScreen. So the new LoadingScreen can be shown in place of either the RoomScreen, InviteScreen, or SpaceLobbyScreen while they are waiting to be received from the homeserver.

Hi! @kevinaboos , sorry about too late to reply you.

I kept the RestoreStatusView Widget and did not delete it, but I replaced all instances of the RestoreStatusView Widget with the RoomLoadingScreen Widget.

Hi! @kevinaboos , sorry about too late to reply you.

No worries!

I kept the RestoreStatusView Widget and did not delete it, but I replaced all instances of the RestoreStatusView Widget with the RoomLoadingScreen Widget.

Ah ok, I see what you were going for. However, it's a lot different than the original goal I had for a "loading screen" (or "landing page" or "splash screen", whatever you want to call it). For now I'll call it the "LoadingScreen", although we can use it for many other purposes beyond just showing a loading message.

The goal of the LoadingScreen should be to act as the one and only widget/view that handles any case where we cannot yet display the full contents of another top-level view (the RoomScreen, Invites reen, SpaceLobbyScreen). The entire point is to remove that "is loaded" logic from all of those other top-level views such that they don't have to be concerned with that, which will make them a lot simpler (like they were before).

Thus, the LoadingScreen becomes another top-level view, alongside the other 3 I listed above. The LoadingScreen will have a room ID associated with it, which indicates what room it is waiting for. (later we can have it wait on other events, too)

Then, when that room has been loaded, it can emit an Action that instructs the higher-level widgets (the MainMobileUi or MainDesktopUi) to replace that LoadingScreen with whatever other top-level view is appropriate, like a RoomScreen.

So, in summary, the goal here is to remove the redundant "waiting to load" logic from all of the other views (RoomScreen, InviteScreen, SpaceLobbyScreen, etc) and to have just a single LoadingScreen widget that handles all of that.

I realize that's a lot of work, so I'm happy to tackle that myself too, if you like, since it's such a complex change.

Thanks for your review!

i understand your mind. like remove the loading logic from RoomScreen, InviteScreen, or SpaceLobbyScreen. The loading screen view will handle loading status.

I realize that's a lot of work, so I'm happy to tackle that myself too, if you like, since it's such a complex change.

However, I still want to try to address the content of this PR.

I will try and redesign it as soon as possible.

However, I still want to try to address the content of this PR.

I will try and redesign it as soon as possible.

Great! No rush.

I took a second look at the code, and I think you're actually further along than I thought yesterday, so that's good. Hopefully it won't be too much extra work.

Another thing that we can use this LoadingScreen for is to show it as a temporary view when the user has clicked on an unknown room/event link. We can then show the LoadingScreen while the room is being resolved & fetched. It could also be used as a intermediary/placeholder screen for other cases too. (These extra use cases will be added in the future, I'm just mentioning them now so you can get an idea of the bigger picture and my general goals for this widget 👍)