vscode-titlebar-less-macos
vscode-titlebar-less-macos copied to clipboard
lehni
Bring this into VSCode proper
Cross posting here from: https://github.com/microsoft/vscode/issues/12377#issuecomment-507240068
Would be great :+1:
Okay, given that some kind of inline titlebar might actually get into VSCode, here's my 2 cents. I recently published extension, that amongst other things also implements titlebar less on OS X (inspired by this extension, obviously :)
There are some differences though. @lehni's extension makes activity bar very wide, which might not be the behavior you'd want in stock VSCode. It's a huge chunk of screen estate gone. My extension tucks the activity bar below the traffic lights, and if desired, let you specify background color for the titlebar (traffict lights + sidebar title). I.e.
which might not be the behavior you'd want in stock VSCode.
That's exactly what I want as a user, your proposed alternative IMHO looks pretty confusing.
which might not be the behavior you'd want in stock VSCode.
That's exactly what I want as a user, your proposed alternative IMHO looks pretty confusing.
I agree it's not ideal, but neither is resizing activity bar from (already quite large) 50px to 78px. That's a lot less space for actual code.
Tbh, I'm not a fan of vertical activity bar in general, that's why I added setting to move it to the bottom, but that's a separate issue.
@bpasero I'm finally finding some time to answer this:
@lehni I tried your extension today and must say that I am impressed by how you deal with the corner cases (activity bar hidden, side bar hidden, side bar to the right). Very well done 👍
That said, would you be willing to move your changes into a PR to merge this into VSCode as core experience? The way I could see this working is by providing another window.titleBarStyle option inline. > This setting would only be available on macOS, at least until we figured out a solution for Windows/Linux.
🔗 https://github.com/microsoft/vscode/issues/12377#issuecomment-507240068
Thank you for the kind words! I'd be happy to work on integrating this into VSCode, but I'd probably need some help doing it the right away. Since we're both based in Zürich, we could even meet and discuss this over lunch or beers :)
But it sounds like VSCode needs to adopt Electron 6 first, right? I can keep maintaining the extension until then...
Thank you for the kind words! I'd be happy to work on integrating this into VSCode, but I'd probably need some help doing it the right away.
You already did all the changes into a patch, right? We can start from that and then see if something can be done in any better way.
Since we're both based in Zürich, we could even meet and discuss this over lunch or beers :)
Yes! though I will be out on vacation soon, but we can connect when I am back.
But it sounds like VSCode needs to adopt Electron 6 first, right? I can keep maintaining the extension until then...
We have a branch going with Electron 6 (electron-6.0.x) to test things. Are you referring to a particular issue that is fixed in Electron 6 for this to work?
You already did all the changes into a patch, right? We can start from that and then see if something can be done in any better way.
Yes, for that I actually worked with the VSCode source to find the right places and then condensed it into a patch. So I have some understanding of the code base. Some things are rather hacked together though :)
Yes! though I will be out on vacation soon, but we can connect when I am back.
Happy holidays! Will you get in touch when you're back?
We have a branch going with Electron 6 (
electron-6.0.x) to test things. Are you referring to a particular issue that is fixed in Electron 6 for this to work?
I'm thinking of #24 that I thought was resolved in that version? Maybe I'm wrong about this.
I see, yeah we can start on the PR and then see how it works out. At the same time we are working on updating to Electron 6.
I will be back beginning of August and can ping here again then.
@knopp it may be that the people who are happy with the status quo are also Slack users? The look was inspired by it:
But taking further cues from Slack, we could go with the traffic lights that have less padding around them, and then also make the activity bar less wide to align with it again. This would mean that the lights wouldn't align as nicely with the labels in the panes and tabs as they currently doo, see:
@knopp come to think of it, this could easily be hidden behind a config switch. I'll look into this soon.
@lehni, I'm not a slack user so I can't say, but in my opinion horizontal screen estate for IDEs is extremely valuable and I'm not very fond of having almost 30 pixels of additional empty space just to accomodate traffic lights.
However, it's quite possible I'm in the minority and most people are fine with sacrificing this screen estate for better esthetics :) Either way, with activity bar at the bottom this is a non issue for me.
All this said, if you go ahead with the patch, there are two issues with your extension that you might want to address:
-
Double click at any draggable area should invoke
windowService.onWindowTitleDoubleClick()to maximize/restore window, -
You might also want to address problem with tabs preventing dragging through sidebar title. To reproduce, just create lot of tabs (so that they scroll horizontally), make sure that last tab is selected and try dragging through sidebar title. It will not work, because tabs have
-webkit-app-region:no-dragset. Apparently, even if element is scrolled away and clipped, this still prevents dragging. In my extension I solved this by creating empty DOM element withwebkit-app-region:dragthat fills the space after last tab, and only in the fist row of tabs. This way, it is not necessary to have no-drag on individual tabs and thus they don't interfere with sidebar title.
You can see the code here.
but in my opinion horizontal screen estate for IDEs is extremely valuable and I'm not very fond of having almost 30 pixels of additional empty space just to accomodate traffic lights.
I think so too, but I also like nice UIs, the way this works for me is that I have a shortcut for toggling the activity bar, unless I actually need it (if I forget what the shortcut for switching between them is) I simply show it temporarily.
Personally I write code that never goes over 80 chars per line, so I can use diffing and such easily when working with git. Thus the wide activity bar never bothered me in VSCode.
I'll give the more narrow traffic lights a go now, but I don't think it's worth going further than that...
@knopp regarding the other things you mention, yes I'll keep them in mind. It'll be much easier to address this when the code is properly integrated in VSCode, not delivered as an increasingly complex patch.
Here a quick sketch of how it would look with the thiner traffic lights. I'm torn about that look, feels like it doesn't have enough room to breathe, but maybe I'm just too used to the status quo now.
but maybe I'm just too used to the status quo now.
Nah, those traffic lights just look ugly, they use a very different padding compared to other elements of the app (see "Explorer" in the sidebar or the editors' tabs), and as a consequence they stop behind aligned with anything on the x axis.
@knopp It still looks off to me, the window's control buttons aren't aligned with anything on the y axis, the border that separates sidebar and activity bar is kind of truncated (doesn't go all the way to the top like the border that separates the editors and the sidebar).
@fabiospampinato
window's control buttons aren't aligned with anything on the y axis,
They're center aligned by the sidebar title and tabs, so I'm not sure what you mean. Did you by any chance meant x-axis?
Did you by any chance meant x-axis?
Yes, sorry 😅
Another thing that looks off to me is that the "EXPLORER" header in the sidebar isn't aligned with the elements in the sidebar. I think this is inevitable when the activity bar is hidden, but when it's visible I'd prefer if things aligned more.
@bpasero ~~since things appear to be breaking in a bigger way again soon (see #36)~~, is it maybe now time to start working on the real integration instead of patching it again for all the underlying changes?
Update: #36 seems fine after another restart.
Yeah, I am a bit flooded by work right now after returning, but feel free to fire up a PR, though I may not have time to jump on it just now 👍
I have deprecated this extension in favour of https://marketplace.visualstudio.com/items?itemName=iocave.customize-ui by @knopp now. Feel free to carry on the discussion of integrating its functionality there!
@bpasero since customize-ui is now broken, would you still be interested bringing the changes of my extension into core? I am still based in Zurich and would be happy to work on this together. We could meet for a coffee and discuss how to best go about it! let's make this a reality. VSCode deserves a modern look!
@bpasero APC is now carrying the torch, but I still think this should become the default style on macOS:
https://github.com/drcika/apc-extension/issues/52