Mac: Provide a setting to hide the title bar and inline the window controls

[orta]

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: https://github.com/orta/vscode/compare/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.

[orta]

Here's a GIF of me prodding and poking around with it too

[joaomoreno]

Good Lord, this looks amazing.

[bpasero]

@orta cool! how does it work though if you have a whole bunch of tabs open to the top? no more window drag?

[orta]

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 )

[joaomoreno]

Which is still pretty ugly. But you can always drag it from the space around the Close, Minimize and Maximize buttons, can't you?

[orta]

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:

[joaomoreno]

Oh wow. That's just awesome.

PS: I learned something today: traffic lights!

[bpasero]

@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.

[orta]

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

---

[joaomoreno]

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.

[hochem]

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.

[bpasero]

@stevencl @bgashler1 fyi

[bpasero]

@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 👍

[Tyriar]

@orta the final screenshot in https://github.com/Microsoft/vscode/issues/12377#issuecomment-248674424 probably can't happen as extensions will be able to contribute viewlets with associated buttons on the activity bar soon (#12163).

[orta]

@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.

[octref]

@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

[orta]

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:

[orta]

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 )

[bpasero]

I am not sure if that is possible but I do agree that it would be nice 👍

[bgashler1]

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.

[bpasero]

@bgashler1 this is a feature which to my knowledge only works on Mac

[Tyriar]

@bgashler1 I would have some objections if we tried to mash the macOS traffic lights into the Windows and Linux clients.

[bgashler1]

@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.

[orta]

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

[orta]

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 )

[orta]

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.

[hochem]

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.

[orta]

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.

[bpasero]

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.

[bpasero]

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.

[orta]

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

[bpasero]

@orta I need an event...

[orta]

A VSCodeWindow has a reference to it's BrowserWindow which can emit events for the full screen toggles - they probably work like these events

[bpasero]

A bit ugly because you cannot listen from the renderer side, but yeah, looks like a valid option.

[bpasero]

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.

[orta]

Cool, no problem, at least that problem was already solved for us

I'll update/revert the activitybar sizes/margins in full screen scope 👍

[bpasero]

Ah nice to see that Mac OS takes care. Yeah, was referring mainly to paddings.

[orta]

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

https://github.com/orta/vscode/compare/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.

Build here

[bpasero]

@orta cool, can we put this behind a setting so that it is possible to play around with it?

[orta]

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?

[bpasero]

@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.

[orta]

👍 I've got pretty far on that ^ technique - I'll start a PR once I've got it working

[smlombardi]

@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?

[orta]

@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

[seiflotfy]

can we please have that :D

[jtlowe]

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.

[patrys]

@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.

[jtlowe]

@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"

[be5invis]

But I do not use tabs, how to drag if there is no title bar?

[orta]

With workbench.editor.showTabs as false, the entire top section is draggable - we covered that in the PR 👍