Mac: Provide a setting to hide the title bar and inline the window controls #12377
Comments
|
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 |
|
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
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. 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).
|
|
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:
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.
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.
Yep, definitely!
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.
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.
Yeah 👍 cool cool |
|
On macOS, I recommend using the Customize UI extension, along with these settings in your {
"window.titleBarStyle": "native",
"customizeUI.titleBar": "inline",
"customizeUI.activityBar": "wide"
}It's a great replacement for my now defunct Titlebar-Less VSCode for macOS |
|
I want this setting in the build-in, not the extension |
|
|
|
@danilinus check here for my solution to this problem: iocave/customize-ui#94 (comment) |
|
Any updates on this? It's been over 6 years now, and Customize-UI is dead now, while both Discord and Slack have resolved this in their Electron apps. |
|
Maybe we can give Jetbrain Fleet a try. |
|
There's an issue linked to above that seems to be exploring this further: #168671 |
|
They killed Customize-UI, but this issue has been open for 6+ years. Maybe it's time to prioritise this? |
|
Agreed. This is the only thing I want to change in my setup! |
|
Any updates on this? It's been nearly 7 years now. |
|
Any updates? 2 years ago I somehow managed to hide title, with monkey patching and advanced ui settings plugins, and it worked fine. |
|
??? |
|
I wonder why VSCode is on GitHub if even the highest voted issues are just blatantly ignored... |
|
With customize UI not working anymore, this issue suddenly became very annoying. |
|
@kanekv see here for a workable solution for the time being: iocave/customize-ui#156 (comment) |
|
I mean, is it really hard to do? Maybe we can just crowd source some fund and hire someone to do it and send the PR. I think everyone here are willing to pay few $ to see this fixed soon. |
|
04.06.2023, 02:48, "Jürg Lehni" ***@***.***>***@***.*** see here for a workable solution for the time being:iocave/customize-ui#156 (comment)iocave/customize-ui#170 (comment)—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
come on microsoft, let me forget that I'm using an electron app and let me live the fantasy where vscode is a native app 😭. I swear one more annoying thing with vscode and I won't care how much I suck at vim. I'll do it 💀 |
|
People are buying new Macbooks just to get the 10 extra vertical pixels, and VS code could give us 20 pixels for free. Microsoft, you can do it! |
|
btw everyone Customize UI came back with a version that works again on the latest vscode! https://marketplace.visualstudio.com/items?itemName=drcika.apc-extension |
|
On windows they seem to place the hamburguer menu up there on the left next to the app's icon, was hoping that would be possible not only on macOS but on Windows too 🙏 |
|
The Apc Customize UI++ extension broke in the VSCode 1.94 update, so afaik there's no longer any way to hide the title bar on macOS: Please give this issue some love! |
|
Ok, after some more digging I found @subframe7536's new Custom UI Style extension 🎉 which provides a new way to hide the title bar on macOS: They built it as a replacement for Apc Customize UI++ after VSCode 1.94, but they had to take a much hackier approach to make it work (regex replacements on minified js files, instead of AMD dynamic
But I still vote for VSCode to support these kinds of electron window options directly, because of how brittle these kinds of extensions always are. 🙏 Adding another motivating example for this thread, using Custom UI Style I can make a frameless VSCode window on macOS (plus no rounded corners, and no traffic light buttons, and some extra font/sizing configs too): // Electron BrowserWindow options
// - https://www.electronjs.org/docs/latest/api/base-window
// - https://www.electronjs.org/docs/latest/api/browser-window
"custom-ui-style.electron": {
// Frameless window (no title bar, no traffic light buttons)
// - https://www.electronjs.org/docs/latest/tutorial/custom-window-styles#frameless-windows
// - https://www.electronjs.org/docs/latest/tutorial/custom-title-bar
"frame": false,
// Disable rounded corners
// - "Setting this property to false will prevent the window from being fullscreenable"
"roundedCorners": false,
},
|
|
I'm sharing my updated instructions to achieve the subframe7536/vscode-custom-ui-style#16 
|
|
Thanks for sharing these updates guys! From what I looked so far, these tools wouldn't allow me to achieve what I'm looking for with keeping the current native title bar and move the top-horizontal-oriented activity bar up onto the title bar keeping the traffic lights and the command palette and all other buttons that are featured there currently, perhaps just moving the command palette slightly to the right so all of the activity bar icons can fit on the right hand side there? Something like the below:
On windows they have the vscode icon and menu up there while on macOS it's kept outside the window on the OS menu bar, but still would like a way to disable the windows menu in favor of the top activity bar in its place:
They recently added the integrated Copilot icon up there as well and have options to toggle which items you want to show in the title bar, so moving the activity bar there should be possible with custom title bar hacks :)
|
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:
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.
The text was updated successfully, but these errors were encountered: