microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.16k stars 28.53k forks source link

Design exploration for improving experience for new users #115641

Open miguelsolorio opened 3 years ago

miguelsolorio commented 3 years ago

Overview

This design exploration aims to improve the overall experience for new users while also providing value for existing users. Going through feedback from new and existing users we've heard that:

We also wanted to take the opportunity to explore updating the overall aesthetics like:

Demo

Below is an example of this exploration. Here's a few ideas that we tried:

design mockup

https://user-images.githubusercontent.com/35271042/106675880-c02c4e80-656a-11eb-8f5f-ead5e96300ba.mp4

Feedback

Here's the feedback I've received on this concept from our team. I'll break down the concepts into individual issue for those we are interested in pursuing more. Note: since this concept touches several ideas at once, it would be good to break down some changes (like density changes and showing more/less UI should be separate).

Pros

Cons

Happy to hear any additional feedback others have on this concept.

SV9045 commented 3 years ago

I would like to suggest for 'merge' (merging branch) into the git command menu where all the commands such as push, pull, stash etc.. right now using it from command palate !

noman-work commented 3 years ago

Make Floating Terminal Like IntelliJ IDEA 👀👀

MvRemmerden commented 3 years ago

@misolori I really like the concept of adding labels to the icons in the left nav sidebar, it would have been a huge help for me to understand what these are when I started using VS Code.

Have you already thought about how to deal with this is languages where the labels might be a bit longer? As an example, "Extensions" is "Erweiterungen" in German.

karuppasamy commented 3 years ago

Suggestions.

  1. Navigation option "< >" beside the new Omni Search bar to change the activity bar icons.
  2. Dedicated option to navigate (back/forward) to the last cursor position.
fabiospampinato commented 3 years ago

Some random feedback:

I hope I wrote some useful feedback in here, if it sounds harsh I had no intention to offend anybody or anything like that, I'm just an happy vscode user trying to steer vscode more into what I perceive to be the right direction.

fabiospampinato commented 3 years ago
gjsjohnmurray commented 3 years ago

I would like to suggest for 'merge' (merging branch) into the git command menu where all the commands such as push, pull, stash etc.. right now using it from command palate !

@SV9045 is this what you are looking for?

image

(screenshot from 1.52.1)

SV9045 commented 3 years ago

@gjsjohnmurray , Yes This is what I was looking for , sorry I didn't check it, apologize.

but I would like to suggest one enhancement though, I remember in my initial days when I started to using git it was confusing for me that I'm merging my own branch to the base branch but it's actually I'm merging base branch to my own branch while working in multi team environment. so, something like merge base branch or might be we can see base branch here and we have an option that, merge it into the current branch. It would be useful to avoid confusing and for understanding git flow when some new person will start using git through VS Code.

gjsjohnmurray commented 3 years ago

@SV9045 please don't use this issue for specific enhancement requests. Instead, start a new one. A convenient way to do this is from "Report Issue" off the Help menu. Pick "Feature Request" and enter details.

jeffrafter commented 3 years ago

This looks fantastic ✨

Features that I use on a daily basis seem far more discoverable. My sense is that this will do more to increase productivity generally than simply target new users / onboarding. Which is great!

Some small feedback:

tvanantwerp commented 3 years ago

Moving a search field and the user & settings icons into the top bar give it more of a Microsoft Office feel. Which IMO is unfortunate–VS Code is one of Microsoft's best products, and the others should be emulating it and not vice versa.

I like the left bar icon labels, though. I still haven't clicked on all of them because I don't know what they are.

I'm not sure why "Explorer" text is so much larger than everything else.

alefragnani commented 3 years ago

First of all, congratulations for the design and detailed information. It helps a lot with the understanding and feedback 👍

I understand, and agree, the idea for improving experience for new users, and indeed some of the features would help them. But as a long time user, I agree with a lot of @fabiospampinato comments , and would like to add comments on two areas that I fear most.

The new design follows a few of MS Teams identity, which is good on a guidelines point of view, but these two points are exactly the ones I struggle the most, specially the Omni search. Slack has the same issue.

Being new usersthe main audience for these changes, I would ask you to release it as opt-in, so current users aren’t affected.

Thank you

miguelsolorio commented 3 years ago

Thanks everyone for the feedback! Here's some responses to everyone's comments:

Have you already thought about how to deal with this is languages where the labels might be a bit longer? As an example, "Extensions" is "Erweiterungen" in German.

Adding labels to the Activity Bar icons is a waste of valuable space, and will probably break when you deal with translations and the new icons provided by extensions. Take the Remote - Containers Extension as an example, the icon’s name is Remote Explorer. How it would handle it? Line break or ellipsis? But, a simple context menu/setting to “hide” the labels would work.

I did think about this and that's the biggest hurdles with text labels. An alternative would be to add a bit more padding for languages that tend to have longer names, but we'd need to test that with users to see how much that is affected. I also thought we could add a "short name" property that allows an extension to have an abbreviated name, if the extension name is long.

Dedicated option to navigate (back/forward) to the last cursor position.

I did play around with adding this as < > icons like Slack, but because Windows uses the file menu caused this to not work well across other platforms.

Traffic lights buttons on macOS don't have equal vertical padding around them, especially in the non-dense version but also in the dense version, IMHO that's the kind of detail that drives people like me crazy. Those buttons can be repositioned dynamically at runtime and I think they should.

One small nit - I think the window controls on MacOS should be centered vertically:

Yes, this is a visual bug. Thanks for pointing it out!

Labels in the activity bar are kind of only useful the first time one opens the app, you need people to understand what everything does, but you don't want to bloat the UI endlessly for ~everybody who has already used vscode for a few days. The compact design gets rid of them but IMHO we should get rid of the compact toggle too, I'll get to that later. I think Discord's approach to this is better, they show tooltips on hover and that's it, that way you also solve the issue of labels that are longer than "Extensions" and won't fit in the current design.

Adding labels to the Activity Bar icons is a waste of valuable space...But, a simple context menu/setting to “hide” the labels would work.

We'd definitely create options to toggle these on/off, just like we do for our various settings 😄

The height of the toolbar in the view container is ridiculously high, you can fit like 3 or 4 tree items in here, IMHO it just looks excessively tall for the sake of it and has no actual purpose, it actually wastes some vertical space and some horizontal space from toolbar buttons. It'd be much better IMO if it just aligned with the tabbar in height, currently it just looks odd.

The padded line highlighting the active item in the activity bar looks nice, but maybe it's acually useless? Like it doesn't really have any purpose, it only makes the "Explorer" item more visibly active in the mockup because the git item has a blue badge too, once the badge is not the ~same color as active items anymore this problem disappears. Plus tabs can also have an highlight line like that, now should that be padded too for consistency? Probably, but that'd waste extra space for nothing too.

There are going to be users who prefer having more space/padding around items and those that do not, this would definitely be a setting to let users control.

It just breaks some workflows where one would go through search results, with search results on the left and editors on the right, now you can't see both at the same time. I suppose one could open searches on their own editors and manage them that way, but that's not the same thing at all, now you can't just collapse the sidebar temporarily and commands like the one for closing all tabs mess with your workflow.

The "replace search with omni search" is something we're definitely evaluating, there would likely be an option to place Search in the sidebar/panel/title. Lots of gaps to fill in.

Even visually I'm not sure it actually works, on macOS it looks good, on Windows not so much if you shrink the width of the window a bit more, what would happens if there isn't enough space for rendering the whole thing? Besides it's off-center all the time and that's already triggering my zen senses.

This would need to be dynamic and shrink to the area. It being off-center on Windows matches the current behavior with the title.

Moving the user and settings icons to the titlebar sounds like it might be nice at first, but you don't actually want a titlebar at all I think, and maybe the statusbar should be used for this, at the end of the day in this mockup it looks like a top statusbar got added, and we already have a bottom one.

The one drawback of placing an omni search in the title bar area is losing the title bar text, so again this would be something that could be configured. This is has also become a common pattern in a lot of apps and our main issue we were addressing here is that settings/accounts have menus and all activity bar items have views associated to them.

Maybe the idea is not to clutter the statusbar too much and to have those "special" items more easily discoverable, IMHO I'd much rather like to see the statusbar getting uncluttered, there's a fair amount of useless information getting shown there (0 errors and 0 warnings, ok, why is the statusbar item there then? Or for example the official github extension, which I'd imagine a lot of people have installed, last time I tried just wasted considerable amount of space just for telling me my own github handle all the time, maybe more focus should go into resolving these issues first).

You can actually right-click and hide items on the status bar. We've also have been doing work to improve the "accounts" experience with our authentication api, so extension should not be showing accounts in the status bar once they move to this. The GitHub PR extension uses this now.

In the mockup custom menus are always used in place of native ones, IMHO that's a regression, and there are some things that custom menus can't really replicate, like being rendered outside of the app canvas. On the other hand though custom menus can display chorded shortcuts normally, but you've gotta use native menus anyway for app-level menus under macOS and Linux so maybe it's just better to be consistent in that regard too.

The mockup is showing the native menus on macOS Big Sur, so those are not custom.

I am not sure I see enough of a distinction between the density modes - why not pick one and leave the other density to theme developers?

This is something we are experimenting with and why we are looking at the feedback. The main thing that the density controls is the amount of padding around items and the font size.

The search panel on the left is moved (now part of omnisearch?) - how do you display lists of results for things like find-in-files?

The Omni search can’t be a replacement for the Search nor the Command Palette. Being a two-step command, makes it hard to accomplish their simple task: Find file that contains a text or Find a command. Personally, I don’t remember an Omni search on any app/website, that ever knew what I want to search, and always forced me to take a second step, to filter on the result. IMHO, it’s the biggest regression compared to the productivity I have today.

The idea I was exploring here was using the Search editor for the replacement of find in files, so when you are typing the first item is always the option to open the find in files. You can also go directly to that mode via the keyboard shortcut (Cmd/Ctrl+Shift+F) and same would apply for the command palette and quick open. If users don't care for omni search, there'd be a toggle to turn it off and Search would go back in the activity bar.

Being new usersthe main audience for these changes, I would ask you to release it as opt-in, so current users aren’t affected.

I've mentioned this a few times, but yes of course we'd also include an option to toggle certain things on/off as we do with other settings. Customization is at the core of our product and we'd always want to strive to maintain that.

fabiospampinato commented 3 years ago

An alternative would be to add a bit more padding for languages that tend to have longer names, but we'd need to test that with users to see how much that is affected.

That doesn't work, a label could be arbitrarily long, you can't add an arbitrary amount of padding to account for that.

I also thought we could add a "short name" property that allows an extension to have an abbreviated name, if the extension name is long.

That'd be kinda ugly, and doesn't work either, there might not always be a short way to express a long label. The solution is that there shouldn't really be labels to begin with, or one accepts that labels can get truncated at some point, which somewhat defeats the whole purpose of labels depending on when the truncation happens.

We'd definitely create options to toggle these on/off, just like we do for our various settings 😄

That's great, I'd just like to uselessly emphasize (I'm not saying anything new) that defaults are important though, the more settings one needs to change to get the app to behave perfectly the more annoying it becomes to use. Now vscode has a lot of slack currently in this regard, like I don't even know which other comparable editor I could switch to, but if another really good editor shows up and they have much better defaults new users might just use that instead, defaults are important.

There are going to be users who prefer having more space/padding around items and those that do not, this would definitely be a setting to let users control.

This logic can't be extended indefinitely, like nobody actually prefers to have 2000px or more of padding around toolbar labels, in my opinion the percentage of people that would prefer to have that much padding around toolbar labels as shown in the mockup is approximately ~0%, and the ones who may actually prefer that are basically wrong really, like some people like to harm themselves, that should be discouraged even if they like it.

This would need to be dynamic and shrink to the area.

Right but what if the area available becomes ~0px? The menubar takes already a good amount of space, at some point there just won't be enough space left for the omnibar.

It being off-center on Windows matches the current behavior with the title.

Sure, that's not really a feature though, and depending on how the omnibar gets implemented it may be a lot more dynamic that the pretty much static title which I personally pay next to 0 attention to.

our main issue we were addressing here is that settings/accounts have menus and all activity bar items have views associated to them.

IMHO settings should have its own view (non constrained to an editor tab) to make it always usable again and the account icon should be moved to the statusbar or potentially gain a view too.

I understand though it there's a push to make the family of MS apps more consistent which it other, that's worth something, I'm just biased on this because I just personally don't care one bit about any other MS app.

You can actually right-click and hide items on the status bar.

Of course, but that's an approximation of what one wants, what one wants, or what I want anyway, is to have only useful information in the statusbar and no totally useless information, hiding or showing a statusbar item is only the perfect solution to the problem as long as the item is always useful or always useless, but I can't just hide the problems item or the notifications item only when they are being useless, they themselves should be more self conscious about how they use the limited amount of use space available. You guys obviously can't fix this for third-party items too, but I would expect the official ones to be more conscious about this.

The mockup is showing the native menus on macOS Big Sur, so those are not custom.

So on linux and windows they are custom? Would it not make sense to be consistent about this across platforms?

alefragnani commented 3 years ago

Hi @misolori ,

The idea I was exploring here was using the Search editor for the replacement of find in files, so when you are typing the first item is always the option to open the find in files. You can also go directly to that mode via the keyboard shortcut (Cmd/Ctrl+Shift+F) and same would apply for the command palette and quick open. If users don't care for omni search, there'd be a toggle to turn it off and Search would go back in the activity bar.

That’s great. Doing so, users who enjoy using Omni search will have it available, and those that don’t, still can use the original behavior. Just out of curiosity, would the Search feature still have its results show in the Side Bar, right?

BTW, I would suggest to add Settings to the Omni search as well. Maybe, this is what the user is searching for 😬

Just to be clear, I don’t dislike the Omni search element itself. In fact, I think it uses the perfect location, and the Settings icons at top right fit great as well. My fear was you were adding the Omni search as a replacement to the Search icon. But if the Search feature is still available, that’s great!

There are going to be users who prefer having more space/padding around items and those that do not, this would definitely be a setting to let users control.

Looking at this, I remembered a pain point while using the Source Control panel today, which you solved with the non-dense mode. Today, it’s hard for me to use the Commit button, specially with the revamped thinner icons. Maybe because the Commit button is not the first, maybe because it is not always visible, but the Commit button you added bellow the commit message, helped a lot. I’m not saying it should be used in the dense mode, but if I would change something in that view, it would be this one. Make the Commit button easier to find/distinguish

Thank you, and congratulations for your hard work

yume-chan commented 3 years ago

Adding labels to the activity bar

I think Discord's approach to this is better, they show tooltips on hover and that's it

I prefer this solution. dock in macOS and taskbar in Unity Desktop environment also use this approach.

Moving account/settings to the top right

In the mockup the account icon has been replaced with an avatar. With support for multiple authentication providers, the account menu in Code is more like an "account hub", so randomly choose an avatar from all login services may not work.

For the location, although they are not "activities", they exist in the activity bar for a very long time, most users should have been used to them. And it's not like there's no space for them there.

Introducing an omni search to include commands, files, tasks, etc. (also combining text search into this)

I like the idea, but I think it can be better executed.

When it first opens, it should display a list of recent used or frequently used commands/files/tasks, etc.

When user typed something into it, results can be grouped into types, with the one type contains most relevant results displayed at top. There is also a line of links to quickly jump to each group, like

| Text Input Here |

Jump to commands Jump to files Jump to tasks

Commands -- result 1 -- result 2

Files -- result 1 -- result 2

Maybe views can also be added to omni search to allow quickly revealing them.

Dedicated option to navigate (back/forward) to the last cursor position.

I also want this, don't forget #41309 (Add an optional configurable toolbar below the menu) with hundreds of 👍

Introducing a "density" toggle (similar to email clients)

The compact mode toggle IMHO should be deleted, the UI should always be reasonably "compact"

I agree. I don't think the effort put into designing and implementing two sets of density worth the outcome. Also it's very difficult for all extension authors implementing webview-based custom editors and views to adopt.

pixieaka commented 3 years ago

@misolori Search in activity bar is so much clear to take overview of files and number of matches for each file more than search editor.

image

pixieaka commented 3 years ago

@misolori https://github.com/microsoft/vscode/issues/28409 Can this adds in new design? Because cursor with bigger Line height value looks bad actually.

image

irvnriir commented 3 years ago

For me Activity Bar is distracting and takes too much space, so i use "Activitus Bar" Extension . Moving these menus to Title Bar would be a good addition .

miguelsolorio commented 3 years ago

Adding a couple of Fluent design concepts from Zee-Al-Eid Ahmad Rana that are relevant:

image

image

fabiospampinato commented 3 years ago

IMO those look amazing. I'm just somewhat concerned about wasted space. I'd be interesting to see what the app would look like under macOS, where there's one global menubar and it's fairly common not to have a titlebar at all.

benjamin-rood commented 3 years ago

The padding/density of the Win11 concepts is very good. This density is much better than the originally proposed slightly thick line. I'm a longtime/advanced user and I would prefer this myself, honeslty, at least as a optional toggle).

yvvt0379 commented 3 years ago

Looks really fantastic. The menus are moved below the title bar so that title bar looks no longer crowded. However, I think it can be better if the labels of "split editor" and "run" are removed.

Chaphasilor commented 3 years ago

I also have a few thoughts on this, especially after seeing the Win11 mockups.

Let's start with the omni search (not in the Win11 mockups, but could be added):
I believe a nice solution would be to "upgrade" the current command palette with some new functionality. In theory, the palette can already do all of the things offered by the proposed omni search, it simply looks different and works slightly different.
The changes required would be:

As for placement, it should be in the title bar, next to the window title. Align the window title to the left, and have the rest of the space taken up by the omni search

Next up, aethetics:

I prefer the rounded corners and distinct panels/areas from the Win11 mockup, for two main reasons:

The Win11 mockups could be more consistent though, for example:

As for the "density setting", it should be relatively straight-forward to implement for the Win11 mockups:
The density setting only affects the padding of things like Activity Bar items, tabs, the file tree in the explorer view and other listings such as the Outline or Timeline panels.
This should never cause the design to break down, it would simply mean less or more scrolling, depending on the user's preference.
Changing the density could be done by choosing from a dropdown or even manually supplying padding values for each item type.

Finally, moving the text search (ctrl+f) into the omni search will be a challenge. It has some options (case sensitivity, regex) that don't really fit in there, and the whole "replace" field is even harder to integrate. Maybe just leave it be and only use the omni search for local and global fuzzy text search?

Sorry for this lengthy comment, but I hope it will be useful.
I would also suggest you try to get one of the Windows 11 designers on board for this in order to make sure the design is consistent with the new OS :)

xezrunner commented 3 years ago

Adding a couple of Fluent design concepts from Zee-Al-Eid Ahmad Rana that are relevant:

These look absolutely fantastic! They align with Windows 11's design quite well, perhaps even perfectly. I wonder how conceivable this would be in regards to the Electron framework (unless WinUI would be used in some form).

I'd be interesting to see what the app would look like under macOS, where there's one global menubar and it's fairly common not to have a titlebar at all.

If we consider the titlebar as just the row that contains the app title and the window controls, that doesn't seem like an issue. While I do not use macOS, based on what I've seen so far, the titlebar consists of just the app title and the window controls. The window menubar is on a different row and could be hidden, as the global menubar hosts the menus instead (unless configured otherwise - not sure whether window.menuBarVisibility or similar exists on macOS).

Tropix126 commented 3 years ago

These look absolutely fantastic! They align with Windows 11's design quite well, perhaps even perfectly.

Zee's concepts use the WinUI figma toolkit. Their styles can actually exported directly to CSS making replicating WinUI components quite viable on electron. I have a personal project that's highly unfinished which remakes some of the styles into svelte components.

ronnyek commented 3 years ago

not to beat a dead horse, but while we're talkign about trying to improve user experience for new users, is having REAL actual opt-in configurable toolbars still off the table? I feel like that's one of the biggest shortcomings of code, and probably the first thing new users run up against... the fact that people are expected to just memorize 110k commands and figure out how to use command pallete.

MANY MANY MANY issues have been created to address this... and its fallen on deaf ears (probably more likely just really really really stubborn decision makers on the vscode project)

sylveon commented 3 years ago

I know my PR for Acrylic and macOS vibrancy has been closed, but I'd be very happy to start new and make one for Mica and the newer vibrancy APIs, if wanted, to make these styles integrate better with the OS.

hampoelz commented 3 years ago

It might be helpful for an easier implementation ... You can use VS Code already with a Fluent UI look via extensions: with 'Vibrancy Preview' and 'Fluent UI for VSCode'. Unfortunately, after each update you've to enter commands to reactivate the patches.

It's very much based on the Fluent design concepts of Zee-Al-Eid Ahmad Rana.

Would be nice to see something like this as a built-in theme on Windows 11.

image

sylveon commented 3 years ago

@hampoelz I know, I had a PR which added support for this natively (see #52707), and those extensions where created after my PR was rejected, to supplement it.

heartacker commented 3 years ago
  1. ~I want this title bar in Windows~ image

  2. ~let's add an toggle icon to right-bottom status bar~

    Introducing a Terminal toggle in the status bar

  3. some like VS 2019, VSCode waste too much space,especially for laptop PC.

    Introducing a "density" toggle (similar to email clients)

  4. move action Icon from tabs container to alt place

    image

  5. ~want a new another sidebar, only one sidebar is in the soup~ that is done now. 💯 #132893

NuraliMedeu commented 2 years ago

Hello! Will an external PR solve this issue? If so, I can begin working on it. Is all the responsible code in src/vs/workbench/contrib/webview/browser/?

miguelsolorio commented 2 years ago

@NuraliMedeu this is not an issue meant for a PR, please see the good-first-issues or help-wanted if you'd like to help out.

ronnyek commented 2 years ago

Honestly sounds another example of the vscode team dodging UX concerns that countless community members have tried to bring up only to be repeatedly shot down or just ignored all together.

NuraliMedeu commented 2 years ago

@NuraliMedeu this is not an issue meant for a PR, please see the good-first-issues or help-wanted if you'd like to help out.

@misolori , I am sorry, right now I am only interested in improving the appearance of the app. I don't want to deal with its backend problems, which most of the help-wanted issues seem to be.

ayjemabo commented 2 years ago

Improve the UI of the buttons (make them more rounded) [Windows 11]

ghost commented 2 years ago

What if, instead of changing the entire VSCode GUI for Windows, Mac, and Linux to our like, we introduce a more flexible theming API (that uses CSS)? This way we could have native Mac, Windows 11, and Gnome/Yaru themes.

SucculentAnimal commented 2 years ago

Sounds like a great idea, but besides the better theming API I hope they can also provide "better defaults" like more rounded corners or something like that.

duyetnk commented 2 years ago

any update when this design will release ? 🤔 🎉🎉🎉

Spontini commented 2 years ago

I can't wait for this to happen, if ever.

Shomnipotence commented 2 years ago

The first simple thing should be to introduce an acrylic effect to the context menu and menubar menu

image

If you really can't fix the whole design at once, focus on the parts that should be changed first - the parts that are easy in terms of programming and design.

ghost commented 2 years ago

This looks great on a doc, but on real world application things change. For instance, how would it look if the background was custom? What about Windows? Its text rendering (and overall rendering) and buttons are different. Then what about the themes? There would be incompatibilities. I love the design don't get me wrong. But things change when doing the HTML code

With that said, i would love to use this.

sylveon commented 2 years ago

Mica (Windows) and vibrancy (macOS) effects are rendered by the system, not the app, so the effect works as expected with custom backgrounds.

yvvt0379 commented 2 years ago

App just need to invoke the interface provided by OS.

ghost commented 2 years ago

Mica (Windows) and vibrancy (macOS) effects are rendered by the system, not the app, so the effect works as expected with custom backgrounds.

Was not speaking about transparencies. Your design for Windows 11 looks awesome ;)

Shomnipotence commented 2 years ago

Overview image

image

As you can see in the screenshots, in both macOS and Windows native controls, the context menu uses a Gaussian blur effect. So VSC could follow it. Although I know that there are some 3rd party plugins that can do this.

Guidelines In Windows' Design Guidelines it states:

Use background acrylic for transient UI elements, such as context menus, flyouts, and light-dismissable UI. Using Acrylic in transient scenarios helps maintain a visual relationship with the content that triggered the transient UI. https://docs.microsoft.com/en-us/windows/apps/design/style/acrylic Apple HIG

On Apple platforms, a material imparts translucency and blurring to a background, creating a sense of visual separation between foreground and background layers. ……use the menu material for a menu in your macOS app https://developer.apple.com/design/human-interface-guidelines/foundations/materials

Common Point Through these contents, we can easily extract some common features:

Menu uses rounded corners

Translucent material

Gaussian blur

Inner Glow Stroke (in Dark Mode) and Drop Shadow.

Highlights are marked with rounded rectangles

At Last This provides a possibility for this application to not only ensure a consistent experience across platforms, but also conform to the design styles of each platform. Although in order to ensure concise code and maintenance work, we will not prepare different menu styles for different operating systems, but only the above common points, we can already get a relatively good result.

Shomnipotence commented 2 years ago

AFAIK Windows 11 native menus are not an option unless we make a feature request on electronjs server and they add it, since now they only have chrome like menus.

What I'm trying to say is that I'm not requesting a native menu, I'm just requesting an updated menu style to better match the design style of the new generation system.

By the way, I don't reject native menus, it would be great if it could! But it seems like, unlikely?

Kenya-West commented 2 years ago

@Shomnipotence AFAIK VS Code will not support native OS' transparency effects until Electron will do.

If Electron allow to have Mica, Acrilyc, Vibrant or to go complete transparent with custom effect using background (image) as canvas, then every app built on Electron could implement such effect. Until then, VS Code will not offer the feature

Diegorro98 commented 2 years ago

https://github.com/electron/electron/issues/29937 This is a good place to follow the possible progress of Mica in Electron.

Kenya-West commented 2 years ago

electron/electron#29937 This is a good place to follow the possible progress of Mica in Electron.

Glad they began to work with it. But as far as I see, there is much to improve, and Mica support is far from production-ready.