Mac: Provide a setting to hide the title bar and inline the window controls
orta opened this issue · comments
Hello there, a lot of the standard apps in recent versions of macOS have started to inline their titlebar into their tabs, menu buttons etc. I assume this is mainly to save vertical space on laptops. However, like all UI trends, apps that don't quite keep up end up feeling old-fashioned 👯
I started a fork of VS Code that uses the inline style:
There needed to be a few changes:
- I moved the sidebar width to 76, to fit the traffic lights
- I increased the height of the elements that act as the titlebar by one pixel, mainly so that they align with the centre position of the titlebar items
- Allow mouse dragging via the sidebar, and the title elements
Fork: https://github.com/orta/vscode/tree/inline-titlebar
Changes: orta/vscode@master...mac-titlebar-inline
I realise that VS Code is a cross-platform project, and so these changes should probably only be applied in the context of macOS, which I'm happy to look into with some advice (I don't have a windows/linux machine to hand for example).
I also know that no-one wants big unexpected UI changes on their OSS projects, so I've not made it as a PR, but I'd love to know if/what I can do to move this upstream?
Sidenote: If someone can tell me how, I'm happy to make a downloadable build for people to try too, I couldn't find a way to do it - I'm still quite fresh to npm projects.
Here's a GIF of me prodding and poking around with it too
Good Lord, this looks amazing.
@orta cool! how does it work though if you have a whole bunch of tabs open to the top? no more window drag?
Looks like right now the tabs themselves are draggable as the window - which causes bugs as this interferes with re-ordering tabs normally. I can declare them as undraggable easily.
An option here is to have space above the tabs ( Chrome does this for example )
Which is still pretty ugly. But you can always drag it from the space around the Close, Minimize and Maximize buttons, can't you?
Yep, these are the current draggable regions ( I just removed tabs from being draggable )
The traffic lights, and if there is a sidebar open, the title of the sidebar
All of the sidebar:
Any non-tab content of the top bar, including around the buttons on the right:
Oh wow. That's just awesome.
PS: I learned something today: traffic lights!
@orta is it possible to make the side bar size smaller and still fit the window icons? I feel like we loose a lot of horizontal space to accomodate for the icons. I am not sure how people would like that if they care about space for the editor... and in fact, many have asked for a way to hide that sidebar too.
With respect to smaller width, it can, but this is roughly the minimum to ensure that there is a consistent margin applied to the buttons.
Which is roughly the same as say:
e.g. this is 50px as current:
As a counter-argument, the new Slack beta is more aggressive with its management of the titlebar:
which is the same x, y as
It does stick out a bit more, as those positions are the default for not-inlined titlebars ( e.g. normal stick a bar on the top ones, like current ) - with that it is possible to reduce the size down to 68px
Other possibilities are less trivial, Xcode for example has these sidebar menu items above the contextual sidebar
which makes them togglable along with the sidebar when you want more focus:
which, if you'll excuse my quick "rendering" in CSS could look something on the lines of:
There's potential in that, which I can jam on if you're interested (and make a higher fidelity version tomorrow ) - though I'd recommend using the other insets for the traffic lights, then there's a nice visual consistency along the top row
Love the depth you go into this.
I don't really feel the same way as @bpasero and think the width is good. We can even show more in that bar, given the added width, like the keyboard shortcuts to open each viewlet (like Slack) or a label.
Hello! I've also been experimenting with a different UI for vscode and I really like the concepts shown here. I had some very similiar ideas:
But with the completely titlebar-less design (tabs starting at window frame) and multiple editors and tabs it's quite hard to find a good solution for window dragging (which should also be consistent with the default macOS implementation).
Currently I am using this design (again very similiar to the latest image of @orta):
With this design I can easily show and hide the sidebar using a keyboard shortcut and the activitybar isn't taking up extra horizontal space. And there is still a dark titlebar (currently without a title) to drag the window around, but I will probably go back to the default titlebar and just keep the sidebar and activitybar design. This design (or a design where the activity bar can be hidden) would also greatly benefit from a button in the footer (maybe left corner where previously the extensions button was) to toggle the sidebar visibility. I don't have my changes online yet, as they seem quite hacky, are only for the dark theme and they are a part of other changes I made, but if there's any interest, I can isolate and push them.
@stevencl @bgashler1 fyi
@orta maybe when the window goes fullscreen we could revert the additional width in the side bar because then you do not need to host the window buttons in there 👍
@orta the final screenshot in #12377 (comment) probably can't happen as extensions will be able to contribute viewlets with associated buttons on the activity bar soon (#12163).
@hochem - interesting 👍 the inline tabs to the window bar style was something I had considered too! I opted against them for the moment to try and do smaller incremental changes. Mainly so there's less to discuss.
@bpasero - that can happen, for sure, I don't see any current css classes related to being full-screen but that's something I can add to pull it off. I think it makes a lot of sense.
@Tyriar 👍 makes sense
I did some playing around with the production app, this change disables the ability to drag and re-order your editors on the Mac. That could be fixed by adding right click context menus to move them, by adding grab handles to the editor free space or by keeping that to just the command palette commands to move them.
@orta Thanks a lot for the work.
Can you try hiding status bar (View -> Toggle Status Bar) and also hide sidebar + activity bar with CSS? Just want to see how it looks like.
Also, do you know if it's possible to do iA writer like title bar in Electron?
Would be awesome if VSCode has a Zen mode (or distraction-free mode, whatever you name it).
This is what I use in Vim: https://github.com/junegunn/goyo.vim
The titlebar coming and going could be done in electron, but I don't think it would include the animation, I can think of a way to do it in Objective-C, but my guess is that this would require electron changes. I'm also not 100% on how mouse handling would work, but I'm willing to bet there's a nice js callback for that kind of thing, which we can use to trigger it off/on
So I removed all the bits you asked:
Aside from the normal hiding stuff, I also indented the start of the tabs for the first editor by ~70px to make them not clash with the traffic lights.
The cantering of your text layout is possible too:
standalone:
Another weird case is that the zoom in/out features feel weird with this, as it changes the width of the sidebar. Could make the sidebar exempt from the zooming? It could be a safe assumption that people aren't zooming to see those icons any larger ( I mainly use it with pair programming to make it easier for others to see the screen )
I am not sure if that is possible but I do agree that it would be nice 👍
I think it looks visually very cool to inline the title bar. I never liked macOS's native title bar in the default dark theme, because the color contrast is so stark. Very nice work on prototyping this. I have a few usability concerns:
- When the View Bar (aka Activity Bar) is enabled (and it is by default) the added space for fitting the "traffic lights" take away from the coding space. Users love their space there.
- The grabbable areas at the top of the window will be variable, since we we would be relying on the tab well. The tab well could be completely filled with tabs depending on the present situation, potentially leaving little room to grab window aside from the traffic light area (and the View Bar, if it's enabled). This could add cognitive load to a user each time they need to move a window.
- How would this work with Windows, since we need to have top app menu (and it's not separate from the window unlike Mac and certain distributions of Linux)?
- Moving View Bar buttons to be horizontal instead of vertical as they are now will restrict space we have for it to grow. We are planning on adding additional optional buttons to it soon.
I think it would be cool to explore this provided we can address the usability issues and not just make it look prettier. Spotify is doing this cross-platform, and I mostly like how they did it.
@bgashler1 this is a feature which to my knowledge only works on Mac
@bgashler1 I would have some objections if we tried to mash the macOS traffic lights into the Windows and Linux clients.
@Tyriar we would of course never do that :). When I say what would it look like on other platforms, I mean using their respective native buttons for close, minimize and maximize. Particularly on Windows, this is challenging for reasons I mentioned above. I think as @bpasero it's actually not possible. Spotify does something kind of like this, but it seems they're actually theming the native OS title bar for Windows, whereas on Mac it's an inline title bar.
An interesting case for inspiration on what a cross platform version of this would look like comes from some old Firefox designs: http://people.mozilla.org/~shorlander/ux-presentation/ux-presentation.html
To pull off a completely cross-platform version of this you'd need to change the way in which tabs are shown highlighted, and TBH, I can't even think of a way to make the windows menu feel right on every window there.
In the end Firefox (and Chrome) ended up removing menus from the windows versions to make it feel consistent. Which I don't really think is probably what you'd want to do here.
FWIW though, there are design precedents in the windows world for Tabs on top of file menus in explorations for File Explorer but I don't know enough of the ecosystem to really have too much insight.
With respect to how Spotify (and the new Slack client) handles this, they have it pretty easy because they don't need to use that top-space for changing content there's always going to be a set number of items in the top space.
How would this work with Windows, since we need to have top app menu (and it's not separate from the window unlike Mac and certain distributions of Linux)?
So I think realistically/optimistically, this would end up being Mac only. Which is why I've tried to keep the scope of changes as small as possible, as no-one wants to be surprised on cross-platform regressions.
When the View Bar (aka Activity Bar) is enabled (and it is by default) the added space for fitting the "traffic lights" take away from the coding space. Users love their space there.
Yep, definitely!
-
for vertical spacing, as you're saving 25px at the top, and then adding at least 1px to re-center the labelling. Though to work around the lack of grabbable areas, it may require eating into that budget to make a consistent space in the way that Chrome/Firefox do.
-
for horizontal, you're definitely losing ~20px. Personally, I think it's an alright trade to make. The look and feel makes it fit more with the OS, and what other apps native to the platform are doing. I can definitely respect that there are other opinions around this, and in the end it will be your team that makes those calls. I'm effectively just an internet rando that's willing to put some time into this 👍 .
I can explore ways in which you can hide the activity bar entirely, once I set my keyboard shortcuts I mostly work with the sidebar hidden. It might be a case of a horizontal drag indicator and snap at 0 and 76px, but that can be confusing when you support doing both activity bar and sidebar.
iA writer's approach e.g. hiding toolbars when not needed
I will try to take some time tomorrow to think about how this could work elegantly, they have "no actionable elements" underneath where the titlebar would be ( either something you have scrolled through earlier or blank space ) which makes that problem easier.
The grabbable areas at the top of the window will be variable, since we we would be relying on the tab well.
Nice, TIL'd the terminology. I agree, and from using it, I think that realistically it's going to need some top spacing above the tabs to provide some consistency, off-hand I can't think of any designs like this where there is not a persistent top space.
Moving View Bar buttons to be horizontal instead of vertical as they are now will restrict space we have for it to grow. We are planning on adding additional optional buttons to it soon.
Yeah 👍 cool cool
sorry for the long comment - didn't have much time to make some more prototypes
sidenote: I'm still struggling to be able to make a downloadable build, so far I've grokked that I can use gulp vscode-darwin-min to generate the JS, but how can I plug that into an electron shell so that I can ship a version for others to test? ( would love it if you can expand this wiki page with the answers too - this is where I was hoping for the answers )
Alright, got a chance to look at this again, I switched the theme to light VS Code to get a sense of what other themes would look like in the style
With indented tabs:
I also considered what the ability to hide the activity bar might look like
There is a Cocoa (read: Apple provided, and updated per OS) icon that is standard in open dialogues / Safari, that is always used to toggle sidebars
I applied that at the bottom, centered and aligned, with a pretty high opacity in order to not take up too much attention, but to be there if you need it.
With a hidden activitybar, this would mean that the title label of the sidebar would need indenting to avoid the traffic lights
I used debug as the example, as it's the most complicated title in the sidebar. The resizing handling works fine with these changes. The min width would probably need to be updated be the same as it is currently ( e.g. with the current 52px activity bar ) title buttons rest at the traffic lights end naturally.
With both hidden activitybar and sidebar, the tabs would need to be indented
The left part is not a broken layout, but mid-scroll.
I have some rough ideas in my head about what an animating in/out titlebar might look like, but I can't think of any precedents for it except how apple handles the title + menu in full screen mode - e.g.
if you're on a Mac, it's easier to just of full screen on Safari, then move your mouse up and down from the top of the screen to get the sense.
I'd imagine that we could animate down the tabs + title + activity top-margin over the content at the same time as animating in the titlebar, and the actual text of the editor would stay at the exact same position.
Apple call this a "full size contentview" window e.g. the content goes behind the titlebar, if we can animate the toggle of the title bar visibility, and sync up the animation above it could be possible. I don't know how feasible that is with the electron API though.
For my opinion, I think allowing the activity bar to be hidden is doable, but it comes with quite a bit of complexity. There is no obvious answer to "how do I get it back" once you click the thing to remove it other than go to the menu, but that said, that's the same for the status bar at the bottom, so there's a bit more affordability there.
With respect to the tab heigh, these are now the same heights as Safari and in Sierra's new OS provided tabs - which I don't feel negatively affects it too much.
Took another stab at trying to make a build, and got this far :D but here's the compiled JS if you know what to do on your side to test.
I've also been working on some new concepts again, because with the latest activitybar additions my current design will no longer work. And with this new additions a permanent activitybar makes a lot of sense, but I don't want it to be that wide. I'm quite happy with this concept:
@orta Regarding your build issue, can you check, if you got the compiled app in a directory named 'VSCode-darwin' in the parent directory of your vscode source folder? I can compile it without problems and the app is then placed in that folder.
Ohhh, I did not expect it in there! Found it - thanks, PR'd an update to the wiki, I skip all intermediary dirs by using z 👍
Build of the above is available for download.
Lets discuss this for October. I think I can also look into adding a new class to the workbench when you are in fullscreen because then I think the activitybar should not be so wide.
Unfortunately I am not really able to find out when fullscreen changes from within the renderer, if someone has an idea, please let me know.
In theory you may be able to use a check if the screen size for the window is the same as the content frame, in Electron the content frame is made to be full sized during a transition to full screen
@orta I need an event...
A VSCodeWindow has a reference to it's BrowserWindow which can emit events for the full screen toggles - they probably work like these events
A bit ugly because you cannot listen from the renderer side, but yeah, looks like a valid option.
I pushed a change to have a fullscreen class on the workbench container that toggles with this state. I suggest to hook it up with the explorations. I would not expect to see window buttons when I am in fullscreen.
Cool, no problem, at least that problem was already solved for us
I'll update/revert the activitybar sizes/margins in full screen scope 👍
Ah nice to see that Mac OS takes care. Yeah, was referring mainly to paddings.
Alright, I've given this an update, I've also scoped all of the changes to exist only for macOS, and rebased to the current master
orta/vscode@master...mac-titlebar-inline
Window'd
Cropped full screen
TBH, the resizing is a little bit janky, the notification occurs after the change of state (and then has to cross the IPC barrier) and so it moves after the change. It does animate the transition though, so the changes feel deliberate.
@orta cool, can we put this behind a setting so that it is possible to play around with it?
I can, I think this would probably work best by being able to set another css class on the workspace - as most changes exist in the CSS code base. Does that sound reasonable?
@orta yes, but nevertheless I think it needs a reload of the window (actually a restart) to set the proper window options for the inline title bar.
On the main side you can get hold of the IConfigurationService to read from the config and on the main side you can do so as well to add a new class to the workbench (using IPartService.addClass).
Maybe it would make sense to start a PR to discuss the code changes.
👍 I've got pretty far on that ^ technique - I'll start a PR once I've got it working
@orta I edited the workbench.main.css file in your build (as I have in the actual Code 1.5.3) to color the status bar and hide the smiley face. However, your build now warns of a corrupt install (the actual Code does not). Is there a way I can edit the css without causing this?
@smlombardi I'm afraid I don't know, if I had to guess, it's an artefact of the build process - I'm pretty sure I've been building those as dev releases. So they may have additional checks which are stripped in release builds
can we please have that :D
I like this idea of maximizing the editor space. My thoughts:
- May be best to leave the close/min/max button spacing alone. I'm guessing Apple has put thought into this spacing and how it relates to accessibility/usability.
- The close/min/max buttons within the ViewBar make it unnecessarily wide. This would also be an inconsistent width with Windows VSCode, unless its bar was widened as well.
- Instead of getting rid of the title bar, maybe it would be better to re-purpose it as it has been suggested (such as Xcode). It would be great to have a place to dock the Debug Action Pane, as it currently gets in the way while floating over tabs.
@jtlowe good arguments but the "wide sidebar" is now a common thing in many macOS apps. I don't think ~25px of horizontal space is worth trying to come up with something different. I know it's a matter of taste but I'd say it looks better with more whitespace.
@patrys My feeling is that there's not a lot to gain from the proposed wider sidebar designs, in this specific application within its current design. I understand the good points made on keeping vscode modern, but I caution against this being the driving factor. IMO, a great design is one that is logical and natural, but the latest couple of design seem forced. I know there's a good solution to this, and hope it's one that is independent of the sidebar width.
And please don't hate me while I lightheartedly rephrase your comment a little bit in favor of the titlebar:
"I don't think ~25px of vertical space is worth trying to come up with something different"
But I do not use tabs, how to drag if there is no title bar?
With workbench.editor.showTabs as false, the entire top section is draggable - we covered that in the PR 👍
I would argue though that some people (that have tabs disabled) might be equally used to be able to reorder editors by dragging them from the full width editor title, so I am not convinced moving that functionality to a small button is helping those. That was one of the feedback I gave in the PR.
I only see this for MacOS but I would also like to see something similar for Windows and Linux. I generally use the "no menu bar" option so it won't affect me that much of the menu bar isn't visible at all. For Ubuntu's Unity it might not have that big of an issue as it functions similarly to MacOS with it's separate menu bar. But for everything else, possibly just have it appear embedded in the window under the tabs. It could be either permanently visible or have the option to hide it, and only become visible if "alt" is pressed. Much like it functions currently.
Anyways to illustrate what I mean, where to have the menu bar appear from.
How would the "traffic lights" and width of the bar look when the bar is docked on the right instead of the left (configurable in user settings)?
I have pushed a custom title bar implementation to master (see #15098). My plan is still to support this inline title style as one of the available options.
I commented on the outstanding issues the PR still have (see #12628 (comment)).
Someone should jump in and continue the work 👍
@sprinkle131313
This view... I cannot turn off tabs anymore?
Just a concept.
I think the biggest challenge on Win/Linux is the missing main menu bar.
Hmmm...
The top level “-□×” can be put at the rightmost place either, but for tabless layout, the editing panel’s “×” should be carefully handled.
@flagello Do you have a Windows version of this? I mean, close buttons at the right top corner
Nope @be5invis, I would have no way to test it, but it shouldn't be too much work.
@flagello Is it loadable by my extension?
For the Windows/Linux version maybe you need:
- A “VS” button to call out the main menu, and
- Move the “minimize-maximize-close” buttons to the right top corner
Possibly! But you would still need to switch titleBarStyle="hidden" to titleBarStyle="hidden-inset" in "/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/code/electron-main/main.js". I don't know if it can be set via injected JS once the window is loaded, or even before load through your plugin.
In any case I'll have a fork ready as soon as I manage to get past a build error.
It looks fantastic @be5invis! Even better I'd say!
@flagello NOTE: The Side bar should be placed at left to be harmony with the “Great VS Button”. And it should not cover the title bar area.
If Electron had an API to runtime change the titleBarStyle then you could in theory do all of this through your extension after be5invis/vscode-custom-css#5 is merged - this looks nice, much more drastic changes than mine but awesome nethertheless, might give it a shot
</edit> nice one @flagello, got it merged with my changes - in [my fork] (https://github.com/orta/Essence)
Wow really loving the mocks so far, especially the Windows ones. If we ever go this route for Windows, could we have the tab close buttons be thin/hairline, just like the window close buttons?
@be5invis One small suggestion, for the top left button, perhaps you could swap the foreground/background colors? That way the VSCode blue branding is more proheminent, and it looks more like a Ribbon button?
@coreh I'd like so, but these images are photoshopped from anotherone so I did not do such modification.
If Electron had an API to runtime change the titleBarStyle
@orta, I believe that's restriction from Apple's side, not Electron's: you have to set styles for the window (like title bar) during init, not after. So the only way to "switch" styles on the fly is to create another window with identical content but different appearance and switch to that new window.
Should anyone here be interested in a similar direction, I'm maintaining a fork called Essence that sports a frameless window with an enhanced Zen Mode. The affordance problem for dragging is solved by using Shift + Cmd and mousemove to trigger a whole-window drag-area (with keyup and mouseup to restore).
Necromancy with +1!
But as a stopgap feature for fellow Windows 10 users, here's what I did to make it look more natural, like so:
This is done completely through Windows, so you are not doing some weird hack or installing a fork. I was originally writing it as a comment here, but it was really dragging on, so I decided to just go ahead and make a small post about it:
https://zyst.io/how-to-make-visual-studio-code-prettier-in-windows-10
Inspired by @orta's work, I've created an extension for VSCode that allows you to easily activate the titlebar-less mode on macOS:
https://marketplace.visualstudio.com/items?itemName=lehni.vscode-titlebar-less-macos
Please let me know how this works for you all.
@lehni Amazing! Would be perfect if there was support for windows with hidden activity bar. I have created a feature request with some details in your repo: lehni/vscode-titlebar-less-macos#1
@krupenja thanks! version 1.0.3 now addresses those scenarios in all combinations of visibility.
Out of curiosity, all screens and development assuming that sidebars on the left. What happens when we are using the sidebars on the right?
@bcinarli I've addressed that scenario in v1.3.1 of https://marketplace.visualstudio.com/items?itemName=lehni.vscode-titlebar-less-macos
My suggestion is like
where the top left bar is draggable and acts as the title bar.
Hey @lehni, thanks a lot for the awesome extension. Quick q: how I can change "traffic light" colors from red-yellow-green to gray (used Graphite color in global system preference)?
Hey @lehni, thanks a lot for the awesome extension. Quick q: how I can change "traffic light" colors from red-yellow-green to gray (used Graphite color in global system preference)?
That's an issue with Electron, I think. Discord also doesn't respect the Graphite preference...
Oh I see, thanks for the info. That's sad, I hope anyone will find the hack for this :)
How would it work if you have multiple native tabs open?
Edit: And also the activityBar hidden.
@curliq my extension addresses all these situations, maybe you want to check it out?
I think horizontal traffic light layout has some cons:
- activity bar must large than traffic light width.
- user can hide activitybar, explorer. need more logic to control and design.
or put entire activity bar on top, like xcode style.
@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.
I think you are talking about the extension by @lehni, right?
@krupenja oh wow, thanks for spotting that. Yeah I meant @lehni !
@bpasero is there any prior art of extensions being moved into core that @lehni may use as reference? Also, assuming there will be some discussion from other maintainers/owners of VSCode on whether this should be added, is there a way to kick-off that discussion prior to PR in the interest of avoiding unnecessary work? For example, I can imagine there might be a preference to only have OS-agnostic stuff in the core, but I am unfamiliar with the vscode team so I'm just spitballing.
I have an interest in seeing this in core and as I can't do the actual PR I figured I could at least ask questions to try to help that process along 😄
@stackptr my understanding is that the extension is actually not using any of our extension API to get this going, but rather makes changes directly to our core files (which we do NOT encourage). As such I would think it is relatively straightforward to take these changes and turn them into a PR.
For example, I can imagine there might be a preference to only have OS-agnostic stuff in the core
We do have a lot of code in the core that is OS specific, to name an example: support for macOS sierra native tabs or the Windows JumpList.
@bpasero before implementing this in VSCode's core beware that Electron v5 has a bug where part of the window, where the title would have been displayed, becomes unresponsive when using an "hiddenInset" titlebar, the only workaround for it is hiding the provided window controls entirely and re-implementing them.
@fabiospampinato thanks for pointing this out, too bad. But we can still try to look into a fix on the Electron side of things as I imagine it will break quite a bit of applications, like Slack for example?
@bpasero I don't know about Slack specifically but I think they are probably using an "hidden" titleBarStyle. The difference is that the traffic lights have a different padding, the same one that they would have in a regular titlebar I believe, and IMHO look awful.
Fixing this in Electron would be ideal, as I'm sure this is in fact breaking lots of apps.
@fabiospampinato how can an Electron app reliably implement custom window buttons on macOS, I wonder? I recently tried macOS Catalina and there - when you press the Alt key - they show a dropdown with several options what to do with the window (e.g. split in half to the left). Not sure how to get that with a pure HTML solution.
@bpasero I haven't yet tried Catalina, and I wasn't aware of that new feature. The key part here is "reliably", I don't think that popover can be re-implemented reliably:
- It would have to be rendered exactly the same, and that could be very tricky:
- Maybe some shadows, highlights, or the blur they are using can't be reproduced exactly the same with CSS.
- I suppose the icons they are using are copyrighted?
- Good luck providing the same exact texts that macOS provides across all the supported languages.
- If the window becomes narrower than the popover I suppose the popover will be partially rendered outside of the boundaries of the window? That's unimplementable in Electron, unless one's crazy and decides to render the whole thing in a separate transparent window or something and by some miracle manages to position it correctly even when dragging the parent window?
Without considering the popover everything else should be implementable I think, but IMHO it's still not worth it, it's difficult to make it behave exactly the same. For instance a detail I noticed the other day is that if the window is not focused the window controls are rendered in a different shade of gray depending on if dark mode is enabled or not, it's very easy to miss details like this.
Yeah I would rather focus on a fix in Electron than having to re-engineer the buttons. It is already odd that on Windows we have to draw the window buttons ourselves for the custom title bar.
Given the amount of regressions we have seen from the Electron 4 update this week, I would like to refine my statement that I made in #12377 (comment). In order to accept this feature into VSCode, we would need to resolve electron/electron#14529 in Electron because at the same time we are working on the Electron 6 update (#76069) which I do not want to artificially block.