Do not use CSD by default on Linux

[ripefig]

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.

[francoism90]

@ripefig How to disable CSD?

[zhangboyang]

@ripefig How to disable CSD?

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

[sbatten]

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]

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

• Custom title bar uses Windows styling on Linux distributions #65241 has been open longer, so if anything, this should be closed as a duplicate of that
• Custom title bar uses Windows styling on Linux distributions #65241 has much more useful feedback and commentary, including screenshots demonstrating ways CSD in VSCode is broken on Linux
• This bug is about changing the default, not fixing the problems with VSCode's CSD

[wildcart]

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

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)

Screenshot showing Code 1.23 running on KDE Plasma 5.14 (global menu shown)

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]

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]

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]

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]

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]

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.