-
Notifications
You must be signed in to change notification settings - Fork 29.4k
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
Parts splash #53871
Parts splash #53871
Conversation
@jrieken before going into code review, some general observations:
Given the first 2 points I wonder if this should get a bit more support from the workbench, e.g. a |
Thanks, that was an oversight. I pushed a fix but it seems that the titlebar changes color on shutdown. When persisting it is
Agreed, but I wanna keep that out of the first stab on this. Ideally, each part knows what of its children can be persisted, like icons of the activity bar, titles of viewlets and panels, and editor tabs. I think that should definitely be explored but bringing in UI elements early also raises the question of how to signal that they cannot be interacted with.
Yeah, it's a tradeoff between storing more and spending precious compute-cycles on startup. I went with the former. It's around 1k which isn't nothing but also just a 1/10 of my color theme data and a 1/50 of my file history.
Yeah, we should explore but I don't wanna over-engineer this from the start. It's also a tricky question where to put things. Parts only know the inside-world but not how different parts are composted, e.g. the statusbar doesn't know it spreads the whole width of the window but for the parts splash that's important. I think it needs a bit of both, the part should return its inside world with relative sizing and the outside (shell) should persist the overall picture. |
I think this could be because we change the color of the title area when focus is lost to indicate the window being inactive. Maybe on shutdown this actually gets triggered?
Yeah the fact that you cannot click the view icons makes it ugly to show them. Maybe we could go with an approach where it is clear that things are still loading, similar to what Slack is doing in the channel list:
Yeah once we decide to put more into the part itself we should add it probably. |
keep = true; | ||
} | ||
|
||
let structure = window.localStorage.getItem(key); |
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.
This is now the new first access to local storage. I do recall that we have some special perf-ticks for that but I am unsure if that is still the case and iff so where that is.
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.
On Windows I see a scrollbar showing up briefly when I reload the Window with custom title bar.
Settings (Preview) - playground (Workspace) - Code - OSS Dev 10.07.2018 16_16_32.mp4.zip
😱 scrollbar... I wonder how that happens... doesn't look it actually scrolls something. Lets sit on your machine and debug |
I am going home now, but in tomorrow. That div must be overflowing somehow (maybe due to the new title div) |
@jrieken the overflow reproduces for me also in parallels windows, it seems to:
Also in the case of |
That was actually just a typo in the template ;-) |
Yeah, the problem was that some parts take height 100% despising being positioned at an top-offset. |
cc @isidorn |
} | ||
|
||
private _removePartsSplash(): void { | ||
let element = document.getElementById('monaco-parts-splash'); |
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.
Can we put this monaco-parts-splash
into a variable since it is used twice
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.
// activitybar-part | ||
let left = this.workbench.getSideBarPosition() === Position.LEFT; | ||
let activityPartWidth: number; | ||
{ |
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.
All these parts all already aware of their heigth
so I think no height
computation is necessery, you can just get their heigth.
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.
Same for width
.
If we remove the width
and heigth
computation maybe we could reuse some of this code to not compute all these 4 times
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.
@isidorn How/where can I access those dimensions?
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.
@jrieken I thought something like
let part = this.workbench.getContainer(Parts.ACTIVITYBAR_PART);
part.clientHeight
@jrieken I added some comments directly in the code. |
Tried it out on windows and this works nice. Some issues I hit (independent of platform): You keep all these dimensions per Workspace, however most of them we keep globaly and thus a glitch can happen.
Another issue I hit with the Purple vscode, since we always hide the sidebar when purple vscode is opened it seems, and the splash screen does not respect that but paints the sidebar as it was last time I were purple. So apart from my suggestion to keep the splash globaly I would also do a special case for purple splash due to the reason above. |
Is there a (nice) way to get that globally stored width?
That's easy to hardcode. |
Do you want me to dig out all the values you might need here? Just wanted to add that I believe that the purple splash is very important since those are the users that open / close vscode all the time for single file editing and for them percieved startup performence is important - will test it out a bit more. |
Just tried out purple vscode more and no hardcoding will be needed it seems. Since the most common scenario of just opening files works fine.
Not sure how to distuingish this case from opening files in purple. So for me the current behavior works for now. |
I have now pushed a change that makes sure we ignore the sidebar when the workbench state is the empty one. Doesn't look weirdly hard-coded. |
@jrieken checking it out... |
@jrieken works fine. Ok I am pretty puzzled when we decide to open the sidebar and when not for the purple vscode... But overall like the current behavior. |
@jrieken I see you pushed should I check it out again? |
Yeah, merging now. The rest are issues ;-) |
{ | ||
let part = this.workbench.getContainer(Parts.STATUSBAR_PART); | ||
let height = getTotalHeight(part); | ||
let bg = part.style.backgroundColor || 'inhert'; |
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.
inherit
With this PR the workbench stores the abstract structure of some workbench parts so that we can show a preview of those very early the next time the editor starts.