Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not use CSD by default on Linux #65608

Closed
ripefig opened this issue Dec 23, 2018 · 16 comments
Closed

Do not use CSD by default on Linux #65608

ripefig opened this issue Dec 23, 2018 · 16 comments
Assignees
Labels
feature-request Request for new features or functionality linux Issues with VS Code on Linux on-testplan titlebar VS Code main title bar issues
Milestone

Comments

@ripefig
Copy link

ripefig commented Dec 23, 2018

CSD does not have good compatibility on Linux. VSCode's window has no shadows under KWin. VSCode's client-side decorations are inconsistent with both Gnome CSD and server-side decorations, both visually and functionally.

Functional inconsitencies:

  • Can't drag window from a widget area in the titlebar, unlike Gnome CSD. Drag area reduced to nothing.
  • Doesn't follow right-click to maximize.
  • Doesn't respect global titlebar button configurations, on any desktop.

Visual inconsistencies are obvious.

CSD could be default if it was at least consistent with Gnome CSD. Otherwise, I believe this feature should remain disabled by default because the only benefit is a few saved pixels but the downsides are numerous.

@ripefig ripefig changed the title Do not use CSD by default Do not use CSD by default on Linux Dec 23, 2018
@francoism90
Copy link

@ripefig How to disable CSD?

@zhangboyang
Copy link

@ripefig How to disable CSD?

In "Settings", search window.titleBarStyle and set it to native.

@sbatten
Copy link
Member

sbatten commented Feb 1, 2019

keeping this one open as a way to guage feedback on this issue. the custom titlebar provides various accessibility improvements and theming improvements over the electron implementation. as always, this can be disabled with
window.titleBarStyle => native

@clee
Copy link

clee commented Feb 1, 2019

I'm annoyed #65241 was closed as a "duplicate" of this, when:

@wildcart
Copy link

wildcart commented Feb 4, 2019

It's not only the style and order of the buttons, as mentioned in #65241, but also their position: My close button is on the left while the rest is on the right (and it's showing more than min/max/close) and when the window is maximised, the title bar is hidden.

Additionally, my menu is placed in a global menu at the top of the screen (hidden by default) which is also broken when the custom title bar is enabled. So I was surprised to see the VS Code menu again, after updating the package.

Screenshot showing Code 1.30 running on KDE Plasma 5.14 using the custom titlebar
code-1 30-custom_titlebar-plasma-5 14

This can be fixed by using the native title bar, after which 1.30 looks and behaves like 1.23 (the version I ran previously).

Screenshot showing Code 1.23 running on KDE Plasma 5.14 (global manu hidden)
code-1 23-plasma-5 14

Screenshot showing Code 1.23 running on KDE Plasma 5.14 (global menu shown)
code-1 23-plasma-5 14-menu

Some general words about window decorations (because I think it's important especially for Linux users):
It's the job of the window manager, and not that of the application, to render the window decoration because it ensure a coherent UI/UX across all applications. I know that Windows has a very different take on it and look at the mess it creates. 'Every single' software (company) uses its own UI/UX offering different functionality. Even Microsoft programs follow different guidelines (at least 3 as of Windows 10, with VS Code's custom title bar adding one more). But on Linux (and Mac) the window decoration is almost always rendered by the window manager (chromium being an exception, which has an option to not use native title bars - in my distro on by default). This is import to note because each window manager may offer more functionality than simply min/max/closing a window, most importantly moving windows to different virtual desktops, keep-on-top, keep-below, sticky and others(more details in #65241). Letting the application render the title bar makes it impossible to access this functionality which creates a bad user experience, because users don't understand why a certain function they are used to is not working in a certain application while it works fine in 'all' others. Some window managers may offer 'other' ways to access the title bar right-click-menu, KWin has the ALT-F3 shortcut, but this is normally not known by everyday-[Linux-]users, hence the functionality is hidden/inaccessible!

In summary, the custom title bar breaks a lot of feature on Linux, the benefits compared to its drawbacks for Linux users is, well, zero.

Thanks for considering
Christian.

@zachbr
Copy link

zachbr commented Feb 4, 2019

The closing of the prior ticket for this one seems to indicate that there is no desire to fix the issue of the CSD on Linux and instead they plan to just disable it outright if there is enough outcry.

I'm not sure why its a matter of outcry at all. As has been brought up over and over again, the CSD fails to integrate with the desktop environment. It doesn't properly handle desktop theming, it doesn't properly handle window control order or positioning, and it doesn't implement any of the "extras" added by certain DEs (like window-shade, move to workspace, etc).

I am less interested in "who" renders the title bar, as this can be argued depending on window manager, desktop environment, distro, day of the week, etc. However I am interested in vscode's intentions not to even try and integrate and support basic features of the platform its running on. And if that is the case, why do we need to have this discussion at all.

Would this issue even have been necessary if vscode shipped a mac style title bar with traffic lights on Windows? Would this issue be necessary if vscode shipped w/ windows style title bar on macOS?

I sincerely doubt it. You'd just not do it, you wouldn't want to gauge feedback on "how bad it is".

@sbatten
Copy link
Member

sbatten commented Feb 4, 2019

As has been stated, the custom title bar and menus provide a more cohesive experience within the application regarding theming along with the primary focus of custom menus, accessibility improvements. I do understand that this is not a priority for all Linux users and this is why the setting to revert will remain an option.

Arguing that we should support the various different things that DE can contribute on Linux as we have matched Windows/macOS is not a fair comparison as Linux is highly customizable. In this regard, we have once again, opted to allow the user to revert to the setting that allows them to keep all DE customizations that they prefer. Some customizations like having the the window controls on the left side are a bit simpler which is why that issue has remained open for consideration. Supporting different icon styles, colors, heights, shadows, etc are all likely beyond the scope of VS Code.

@wildcart
Copy link

wildcart commented Feb 4, 2019

Arguing that we should support the various different things that DE can contribute on Linux as we have matched Windows/macOS is not a fair comparison as Linux is highly customizable.

Thank you for making the point for us: Simply don't!

It may create a "more cohesive experience within the application" but it totally breaks the "cohesive experience" of a user across all applications on the platform the application runs on. Do you really think that each application shipping its own "cohesive experience" is good for overall user experience?

@zachbr
Copy link

zachbr commented Feb 4, 2019

Ultimately @wildcart's reply is the exact point I was trying to make.

In this regard, we have once again, opted to allow the user to revert to the setting that allows them to keep all DE customizations that they prefer.

Breaking desktop cohesion by default and then offering the user a choice to revert it is backwards. I would absolutely again draw you to the comparison to Windows or macOS applications. Many of them do not fully integrate with Windows or macOS as a platform, but they don't ship their own visually distinct title bar or window frame or other major UI component, and those few that do must either take special care to fit the environment or are rightly ostracized for it.

As has been stated, the custom title bar and menus provide a more cohesive experience within the application

So it's fine to break desktop cohesion if it means the application appears to be more cohesive? That doesn't sound well rooted in any platform or application design schema I've ever heard of. I'd be willing to bet there are guidelines that state just the opposite somewhere on Microsoft's site advising Windows application developers to avoid it.

theming along with the primary focus of custom menus, accessibility improvements

If this is the crutch of the argument perhaps we should dive deeper into custom menus and enumerate the accessibility improvements so that it is possible for the vscode linux community, and even the larger vscode community to have a more informed and encompassing discussion.

@clee
Copy link

clee commented Feb 5, 2019

Arguing that we should support the various different things that DE can contribute on Linux as we have matched Windows/macOS is not a fair comparison as Linux is highly customizable.

Saying "we won't do it right on Linux because it's hard" is frankly unacceptable.

Either disable the feature entirely, or make an actual effort.

@ripefig
Copy link
Author

ripefig commented Feb 12, 2019

The problem with CSDs on Linux is fundamental. It took Mozilla a whole year just to create a CSD that looks at home in a Gnome environment (of course you can forget KDE).

The only way to really solve this is DWD, a project that KDE started several years ago and then abandoned: https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/

@sbatten
Copy link
Member

sbatten commented Feb 18, 2019

I appreciate all the passionate feedback in this thread. After cosidering the points here and the value of the custom title bar on Linux, we have decided to revert the default for Linux. A short blurb about this change can be found in our Linux docs page.

fixed by #68640

@sbatten sbatten closed this as completed Feb 18, 2019
@sbatten sbatten added feature-request Request for new features or functionality linux Issues with VS Code on Linux workbench-menu titlebar VS Code main title bar issues on-testplan and removed under-discussion Issue is under discussion for relevance, priority, approach labels Feb 18, 2019
@sbatten sbatten added this to the February 2019 milestone Feb 18, 2019
@soncodi
Copy link
Contributor

soncodi commented Feb 19, 2019

FWIW, I prefer the custom title bar to the native look-and-feel. It also goes well with my DE's dark theme. I don't care which is the default, but please don't remove the custom option.

@m-thorsen
Copy link

Could it be an idea to instead revisit a GTK dark mode toggle for better Linux integration? ( Ref: #11979 )
I'm sure this could be extended to other OSes as well seeing that dark mode is a thing in both macos and windows now.

There's an extension for this ( https://github.com/fkrull/vscode-gtk-dark-titlebar ), but that extension doesn't disable itself on other OSes, causing issues when syncing settings across platforms.

@sbatten
Copy link
Member

sbatten commented Feb 21, 2019

@m-thorsen One of the issues I saw in the linked thread and is also mentioned in the extension README is that the menu doesn't change theme with GTK. Is this fixed now with some of the changes that went into electron around menu theming?

@m-thorsen
Copy link

@sbatten No, the method suggested in that thread does not change the menu theme.

There are a few issues filed with Electron on this issue - to link a few:
electron/electron#9681
electron/electron#13381
electron/electron#15878

(Disclaimer: I haven't read through all the issue comments)

Either way I think a dark title bar would be a good starting point - as it at least blends in when the menu bar is hidden.

@vscodebot vscodebot bot locked and limited conversation to collaborators Apr 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality linux Issues with VS Code on Linux on-testplan titlebar VS Code main title bar issues
Projects
None yet
Development

No branches or pull requests

9 participants