feat(gui-client): show "Welcome" screen on 2nd app launch#9136
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| listen<Session>('signed_in', (e) => { | ||
| let session = e.payload; | ||
|
|
||
| accountSlugSpan.textContent = session.account_slug; | ||
| actorNameSpan.textContent = session.actor_name; | ||
| signedOutDiv.style.display = "none"; | ||
| signedInDiv.style.display = "block"; | ||
| }) | ||
|
|
||
| listen<void>('signed_out', (_e) => { | ||
| accountSlugSpan.textContent = ""; | ||
| actorNameSpan.textContent = ""; | ||
| signedOutDiv.style.display = "block"; | ||
| signedInDiv.style.display = "none"; | ||
| }) |
There was a problem hiding this comment.
I am using something new here. Tauri has the ability to send "events" to the frontend and we can listen on those events and update the GUI as a result. This allows us to nicely decouple things. If we get signed out for whatever reason and this window happens to be open, it will automatically update.
I am gonna do the same thing for the settings once I revamp those.
There was a problem hiding this comment.
This is how we do it on Apple and Android. The tunnel can run in whatever state it's in. When a GUI connects, it automatically gets updated with the proper state appropriately.
There was a problem hiding this comment.
Main difference that I want to point out here is that the communication is one-way. We never request data, it gets pushed via an event.
There was a problem hiding this comment.
Also, this is between WebView and GUI client, the tunnel process is not at play here.
The GUI client is basically a backend to the WebView.
The equivalent on Apple is using an observable property in SwiftUI. I don't think we are doing that on Android?
| // Ensure state in frontend is up-to-date. | ||
| match current_session { | ||
| Some(session) => self.notify_signed_in(session)?, | ||
| None => self.notify_signed_out()?, | ||
| }; |
There was a problem hiding this comment.
In order to make sure the frontend is definitely up to date, we dispatch an event every time we show/hide it.
| ); | ||
| } | ||
| Req::SystemTrayMenu(system_tray::Event::SignOut) => { | ||
| SignOut | SystemTrayMenu(system_tray::Event::SignOut) => { |
There was a problem hiding this comment.
Clicking SignOut just triggers the same codepath as clicking it in the tray menu.
| self.integration | ||
| .set_welcome_window_visible(true, self.auth.session())?; |
There was a problem hiding this comment.
If a new instance gets launched, we now show the welcome window here.
| } | ||
|
|
||
| if anyhow.root_cause().is::<gui::AlreadyRunning>() { | ||
| return Ok(()); |
There was a problem hiding this comment.
Detecting an already running instance is now no longer an error for the 2nd client.
| return Ok(()); | ||
| } | ||
|
|
||
| if anyhow.root_cause().is::<gui::NewInstanceHandshakeFailed>() { |
There was a problem hiding this comment.
Failing to communicate with that 2nd instance is however.
jamilbk
left a comment
jamilbk
left a comment
There was a problem hiding this comment.
Makes sense.
What happens if you launch Firezone a 3rd time with the Welcome window already open? Does it open another window or just bring the existing window to focus?
| listen<Session>('signed_in', (e) => { | ||
| let session = e.payload; | ||
|
|
||
| accountSlugSpan.textContent = session.account_slug; | ||
| actorNameSpan.textContent = session.actor_name; | ||
| signedOutDiv.style.display = "none"; | ||
| signedInDiv.style.display = "block"; | ||
| }) | ||
|
|
||
| listen<void>('signed_out', (_e) => { | ||
| accountSlugSpan.textContent = ""; | ||
| actorNameSpan.textContent = ""; | ||
| signedOutDiv.style.display = "block"; | ||
| signedInDiv.style.display = "none"; | ||
| }) |
There was a problem hiding this comment.
This is how we do it on Apple and Android. The tunnel can run in whatever state it's in. When a GUI connects, it automatically gets updated with the proper state appropriately.
A 3rd time is no different to the 2nd time because the 2nd instance always exits right away. It will set the Welcome window to visible which is a no-op if it already is visible. I am not sure if that will focus it. |
thomaseizinger
force-pushed
the
feat/show-app-screen
branch
from
0971afc to
bbd162b
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
|
||
| if visible { | ||
| win.show().context("Couldn't show Welcome window")?; | ||
| win.set_focus().context("Failed to focus window")?; |
There was a problem hiding this comment.
@jamilbk This now does the focusing that you mentioned.
2 participants
Resolves: #8352.