zed
zed copied to clipboard
[Linux] Add option to disable client side decoration / enable native titlebar
Check for existing issues
- [X] Completed
Describe the feature
Hello!
Would be nice if we have an option to disable the client side decoration (enable the default native titlebar).
This way, we could integrate the editor way better with the environment.
Here is an example of VS Code using native titlebar instead of its own:
And here is Zed:
The window buttons (to close, minimize and maximize) are different and the border radius are different. With others windows opened, it looks out of place.
If applicable, add mockups / screenshots to help present your vision of the feature
No response
Another example of why this is important
It would be nice if there is a setting to remove the title bar all together. It takes up space and doesn't really add anything.
I would also like to have the option to enable a native titlebar/window decoration.
Different Linux Desktop Environments (DE) provide different functionality, some of which include
- show/hide (extra) window buttons (min/max/close/... window)
- rearranging the window button order
- move all / some window buttons to the left (see post by JackNWhite above)
- move window to a different desktop/ show on all desktops
- move window to a different activity / show on all activities (KDE/Plasma)
- keep above/below other windows
- tiling options on tiling window managers
- hide the titlebar/window decoration (at least KDE/Plasma)
- include the application menu as hamburger menu (via
libdbusmenusupport, I think) - more Linux DE specific features...
None of these features are implemented by the zed titlebar. Instead, these features are currently inaccessible or are only accessible knowing the keyboard shortcut to open a window manager specific window menu (Alt+F3 on KDE/Plasma), if the Linux DE provides such a shortcut.
Applications like Firefox, Chromium, VS Code, Intellij (new UI), and others allow to toggle between an application specific and a native titlebar/window decoration. zed unfortunately doesn't even allow to show the native titlebar/window decoration on top of the application specific toolbar. Instead, the menu option to toggle the native titlebar is disabled in KDE/Plasma's window menu.
To close my post: I do like the editor, which feels more responsive than some editors I am currently (loving that the editor comes with build in VIM mode).
You can actually switch to window decorations by running with ZED_WINDOW_DECORATIONS=server (original comment)
A setting in settings.json like VSCode has would still be nice though.
only accessible knowing the keyboard shortcut to open a window manager specific window menu (Alt+F3 on KDE/Plasma), if the Linux DE provides such a shortcut.
FYI Zed actually supports the menu you're talking about.
You can actually switch to window decorations by running with
ZED_WINDOW_DECORATIONS=server(original comment)A setting in
settings.jsonlike VSCode has would still be nice though.only accessible knowing the keyboard shortcut to open a window manager specific window menu (Alt+F3 on KDE/Plasma), if the Linux DE provides such a shortcut.
FYI Zed actually supports the menu you're talking about.
Unfortunately, some desktops (GNOME) have not and do not plan to add SSD support on Wayland. Libdecor, however, should work fine.
If you or other contributors are interested, I think the setting ZED_WINDOW_DECORATIONS should have three options instead of two: client, server, and native, which would use libdecor.
@apricotbucket28 thanks for pointing out the environment variable.
Regarding the window menu: I know that I can access the menu (using the keyboard shortcut) but without setting ZED_WINDOW_DECORATIONS=server, the option No Titlebar and Frame is disabled. The option is located in the More Actions sub menu.
Wouldn't the following work?
- if the Wayland compositor supports the xdg-decoration protocol, use it for the titlebar to get a native-looking titlebar
- if the Wayland compositor does not support the protocol (which will be the case for GNOME – they will never implement it), draw client-side decorations
Wouldn't the following work?
if the Wayland compositor supports the [xdg-decoration](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml) protocol, use it for the titlebar to get a native-looking titlebar if the Wayland compositor does not support the protocol (which will be the case for GNOME – they will never implement it), draw client-side decorations
You can already do that with the aforementioned ZED_WINDOW_DECORATIONS=server environment variable. I don't think anyone is willing to add libdecor support and the Zed team has already said that they want CSD as the default.
I think a setting in settings.json for toggling CSD/SSD would be nice though, and a PR for that would likely be accepted. Something like "window_decorations": "server" 🙂
I understand that Gnome doesn't plan on integrating SSD, but a sizeable chunk of linux users do use Gnome. And if VSCode can draw native titlebars, I don't see why Zed can't implement the same.
I understand that Gnome doesn't plan on integrating SSD, but a sizeable chunk of linux users do use Gnome. And if VSCode can draw native titlebars, I don't see why Zed can't implement the same.
VSCode is an electron app, so it uses the Electron implementation, which builds on Chromium. Zed is novel.
If GNOME users want system window decorations, there are a few possibilities:
-
Implement libdecor, which provides the decorations. According to @apricotbucket28, there isn't really an appetite for this, but I would note the existence of libdecor-rs, which, while outdated, may still form the basis of a much simpler implementation Unfortunately, libdecor itself is problematic with modern GNOME as it does not support Libadwaita or even GTK4, and GTK3 themes don't solve some very ugly shadows.
-
Themeable CSD - this is what my money is on, if this problem gets solved. As @apricotbucket28 also said, the Zed team prefers client-side decorations, and this has been a fairly common approach. Many applications (such as Firefox and Chromium, to my knowledge), aren't actually QT or GTK, but simply take the gtk or qt theme's colors and buttons to use in their CSD. LibreOffice takes this even further, with its own GUI toolkit it hooks into GTK and QT not just for CSD but (most?) UI widgets. If Zed's theming capabilities improve to the point icons and spacing can be modified, I would not be surprised if user themes like Zedwaita do so. There are downsides, however. If it is only supported through third-party themes, less popular themes and DEs may not get nice CSD. There may be other discrepancies. Very few apps (Firefox being a recent exception) that don't use libadwaita but imitate it modify corners or shadows to match libadwaita, and other behavior (headerbar color changing when window is focused/unfocused, hovering over close button, etc) might not be implemented.
-
XWayland - currently, running zed with the envvar
WAYLAND_DISPLAY=""(andZED_WINDOW_DECORATIONS=server) still has proper SSD on GNOME. This is what I would recommend to most GNOME users in the present, however xwayland doesn't support fractional scaling well until at least GNOME 47, and even then, I don't know what the results will be on Zed. -
GNOME changes their mind and implements xdg-decoration. I hope this will happen, but I don't have much confidence. The GNOME team seems to believe decorations are an essential part of modern (Wayland) applications, so only xwayland, which is intended for legacy applications that don't support wayland, can have SSD.
After writing this out, I get the feeling there should be a separate issue thread, titled something like "Better/Themeable CSD on Linux" or "Native (style) decorations on GNOME". Zed already supports disabling CSD and enabling a native titlebar through the env var, as has been mentioned. What is there to discuss other than adding it to the Zed settings?
It glitches on COSMIC DE when not maximized
I understand that Gnome doesn't plan on integrating SSD, but a sizeable chunk of linux users do use Gnome. And if VSCode can draw native titlebars, I don't see why Zed can't implement the same.
VSCode is an electron app, so it uses the Electron implementation, which builds on Chromium. Zed is novel.
If GNOME users want system window decorations, there are a few possibilities:
- Implement libdecor, which provides the decorations. According to @apricotbucket28, there isn't really an appetite for this, but I would note the existence of libdecor-rs, which, while outdated, may still form the basis of a much simpler implementation Unfortunately, libdecor itself is problematic with modern GNOME as it does not support Libadwaita or even GTK4, and GTK3 themes don't solve some very ugly shadows.
- Themeable CSD - this is what my money is on, if this problem gets solved. As @apricotbucket28 also said, the Zed team prefers client-side decorations, and this has been a fairly common approach. Many applications (such as Firefox and Chromium, to my knowledge), aren't actually QT or GTK, but simply take the gtk or qt theme's colors and buttons to use in their CSD. LibreOffice takes this even further, with its own GUI toolkit it hooks into GTK and QT not just for CSD but (most?) UI widgets. If Zed's theming capabilities improve to the point icons and spacing can be modified, I would not be surprised if user themes like Zedwaita do so. There are downsides, however. If it is only supported through third-party themes, less popular themes and DEs may not get nice CSD. There may be other discrepancies. Very few apps (Firefox being a recent exception) that don't use libadwaita but imitate it modify corners or shadows to match libadwaita, and other behavior (headerbar color changing when window is focused/unfocused, hovering over close button, etc) might not be implemented.
- XWayland - currently, running zed with the envvar
WAYLAND_DISPLAY=""(andZED_WINDOW_DECORATIONS=server) still has proper SSD on GNOME. This is what I would recommend to most GNOME users in the present, however xwayland doesn't support fractional scaling well until at least GNOME 47, and even then, I don't know what the results will be on Zed.- GNOME changes their mind and implements xdg-decoration. I hope this will happen, but I don't have much confidence. The GNOME team seems to believe decorations are an essential part of modern (Wayland) applications, so only xwayland, which is intended for legacy applications that don't support wayland, can have SSD.
After writing this out, I get the feeling there should be a separate issue thread, titled something like "Better/Themeable CSD on Linux" or "Native (style) decorations on GNOME". Zed already supports disabling CSD and enabling a native titlebar through the env var, as has been mentioned. What is there to discuss other than adding it to the Zed settings?
has a decision been made on this
hi all, is there a setting for this yet or something along those lines? im on linux mint.
@RustoMCSpit
You need to have this for whatever environment you're launching from:
export ZED_WINDOW_DECORATIONS=server
When using Plasma desktop, you can put that in ~/.config/plasma-workspace/env/zed.sh to ensure the variable is set in the context of the graphical session.
You may want to look at this Arch Wiki page to help find a better place to put it for your system, and I expect someone will add a better answer here soon.
super beginner question, what do you mean by "environment im launching from". in the context of what you said, i see a env (which i recognise from python environments. as well as well .sh). if im launching from just Desktop/zed.app/bin, in the default(?) environment, do i put that in my path or something? sorry im not sure if you get what i mean
I would just really like to be able to put the client-side window buttons on the left, and in the order close/hide/maximise (like macOS). Currently they are in the Windows configuration, which makes sense for people who are used to Windows.
I know I can just use server-side decorations via the environment variable ZED_WINDOW_DECORATIONS=server but it is not an ideal solution for a couple reasons:
- It wastes a little bit of vertical space, but more importantly,
- It looks awkward since the Zed window is not really designed for SSD. If you have the toolbar enabled you end up with four layers of headerbar, and the window starts to resemble MS Word.
So my ideal situation would be something like
"window_decorations": {
"side": "client",
"position": "left",
"order": "chm" // close, hide, maximise
}
@DenysMb can you edit your issue at the top to ask for a setting in settings.json
I would just really like to be able to put the client-side window buttons on the left, and in the order close/hide/maximise (like macOS).
Actually, other apps are able to do that on their own, and even extract the system button icons, so Zed shouldn't require specific settings for that.
Thanks
The environment variable has seemingly stopped working recently.
set -gx ZED_WINDOW_DECORATIONS server
In my fish config no longer uses SSD.
The environment variable has seemingly stopped working recently.
set -gx ZED_WINDOW_DECORATIONS serverIn my fish config no longer uses SSD.
I added mine to the .desktop file an its still working for me on kde on nix. I also added it to fish but had no luck there.
Exec=env ZED_WINDOW_DECORATIONS=server zeditor location %U
The environment variable has seemingly stopped working recently.
set -gx ZED_WINDOW_DECORATIONS serverIn my fish config no longer uses SSD.I added mine to the .desktop file an its still working for me on kde on nix. I also added it to fish but had no luck there.
Thanks, that did it.
Really looking forward to this, I use custom button themes (whiteSur-dark-solid) and so it really throws me off that I don't have those. I figured out how to do it with jetbrains which really helped but I am mainly using zed now.
how to enable native title bar style?
how to enable native title bar style?
Go to the desktop file
nano $HOME/.local/share/applications/zed.desktop
Then where it says Exec= place
export ZED_WINDOW_DECORATIONS=server
In front of the path to zed-editor. So the whole line should look like this:
Exec=export ZED_WINDOW_DECORATIONS=server $HOME/.local/zed-preview.app/libexec/zed-editor
Dev's, please add a setting to the settings file. Some people can't do this.
the desktop file
@Wakichiqi
But note this won't work when you launch from the CLI, so you probably want to find a place to set that variable which covers your whole desktop session, instead.
But note this won't work when you launch from the CLI, so you probably want to find a place to set that variable which covers your whole desktop session, instead.
Setting it global has stopped working recently.
how to enable native title bar style?
Go to the desktop file
nano $HOME/.local/share/applications/zed.desktopThen where it says
Exec=place
export ZED_WINDOW_DECORATIONS=serverIn front of the path to zed-editor. So the whole line should look like this:
Exec=export ZED_WINDOW_DECORATIONS=server $HOME/.local/zed-preview.app/libexec/zed-editorDev's, please add a setting to the settings file. Some people can't do this.
I tried this but it did not work but using env worked thank you tho
Hi,
I noticed that the whole Zed trick of running with ZED_WINDOW_DECORATIONS=server works under X11 but not under Wayland, after switching from Linux Mint Cinnamon to Fedora 42 GNOME.
Therefore, the working hack-ish way to do it now is to run it under XWayland.
Thus, you end up with this:
Exec=sh -c "env -u WAYLAND_DISPLAY ZED_WINDOW_DECORATIONS=server zed"
Hope the devs might be able to add this as a temporary setting, with potential native windows to be enabled sometime in the future. I understand that the current transition to Wayland is difficult, and making it work for both Qt6 and GTK4 might be an issue.
Have a good one~
GNOME doesn't support server-side decorations in Wayland, so having native titlebars on GNOME is going to be difficult. There was a comment about this above: https://github.com/zed-industries/zed/issues/14165#issuecomment-2297380547
I am able to remove title bars using this method under Wayland. Which is what I need for Sway.
