-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide predictable startup ordering #5959
Conversation
Co-authored-by: sharon <[email protected]> Signed-off-by: Jonathan <[email protected]>
E2E Tests 🚀 ? |
* | ||
* Returns a promise that resolves to the session ID of the new session. | ||
*/ | ||
startNewRuntimeSession(runtimeId: string, | ||
sessionName: string, | ||
sessionMode: LanguageRuntimeSessionMode, | ||
notebookUri: URI | undefined, | ||
source: string): Promise<string>; | ||
source: string, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a duplicate from a merge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for spotting that, the history of this branch is a little wonky because it was split off from the persistence work due to overlaps! Addressed now.
This is a feature that I didn't realize that I wanted! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This change eliminates the disorienting startup experience that can occur when multiple affiliated runtimes exist (or multiple sessions are running).
Prior to the change, every runtime start or reconnect resulted in the new session taking over the Console and Variables panes and becoming the active session. Practically speaking this meant that startup often showed some flickering as different sessions booted and Positron switched between them on its own, and the session you wound up with when startup was finished might not be the one you wanted or expected.
After the change, sessions and affiliated runtimes are ordered, and only one console session gets to become active. The other sessions are still started -- they just start in the background. The result is (hopefully) a calmer startup experience.
Right now, there is no explicit ordering -- we just go by whichever one was last used. So if you were using Python when you exited, that's what you should see when you open Positron again; same deal with R.
The implementation works as follows:
activate
flag everywhere we deal with session start events to keep track of whether the session should be focused/activated after it startsactivate
if they are the most recently usedAddresses #1044 and part of #1143.
Release Notes
New Features
Bug Fixes
QA Notes