Wayland Support for IntelliJ-Based IDEs(blog.jetbrains.com)
blog.jetbrains.com
Wayland Support for IntelliJ-Based IDEs
https://blog.jetbrains.com/platform/2023/08/wayland-support/
13 comments
Nice. I really want to use Wayland, it feels a lot smoother. I just have too many issues with it atm. Especially when it comes to screen share.
I've found the abstractions with Flatpak, xdg-desktop-portal, pipewire, and misc. web browsers to be decent for screen sharing with Wayland
Native clients, not so much :/
Many-years user of Sway here. My screen sharing is actually broken now, and I'm pretty sure I missed something in my reinstall - it had been great for a year or so
Native clients, not so much :/
Many-years user of Sway here. My screen sharing is actually broken now, and I'm pretty sure I missed something in my reinstall - it had been great for a year or so
I'll have to look into it. I switched back and haven't attempted to switch again but it really was so nice.
Right on - best of luck when you do!
Browsers are my screen-sharing magic, though not every service allows those... or offers an equivalent experience.
What desktop environment/window manager do you tend to prefer? Depending on that you'll likely have to choose/consider a different 'xdg-desktop-portal'.
It may be helpful to share this tool: 'xlsclients'
It can show you things running in that compat mode 'XWayland'. This is usually the explanation for something looking pretty choppy or showing strange clipboard behavior :D
Browsers are my screen-sharing magic, though not every service allows those... or offers an equivalent experience.
What desktop environment/window manager do you tend to prefer? Depending on that you'll likely have to choose/consider a different 'xdg-desktop-portal'.
It may be helpful to share this tool: 'xlsclients'
It can show you things running in that compat mode 'XWayland'. This is usually the explanation for something looking pretty choppy or showing strange clipboard behavior :D
Question for the Linux guys: why does the app developer need to work in Wayland support? Isn't the app agnostic to the display server?
Depends on the framework you used. If you used gtk or qt, it is enough for them to support wayland.
If you have something homemade, or you talk directly to x11 server; well now you have to talk directly to wayland server, using a different protocol.
There are also some changes in semantic, most visible & commented in the screen sharing scenario: with x11, you could just silently grab the desktop framebuffer and run to the bank. That's a no-no with wayland, you must ask a privileged process to mediate the access (and that process will ask the user which display or window to share, if any). Some apps are taking their sweet time to switch to this concept.
If you have something homemade, or you talk directly to x11 server; well now you have to talk directly to wayland server, using a different protocol.
There are also some changes in semantic, most visible & commented in the screen sharing scenario: with x11, you could just silently grab the desktop framebuffer and run to the bank. That's a no-no with wayland, you must ask a privileged process to mediate the access (and that process will ask the user which display or window to share, if any). Some apps are taking their sweet time to switch to this concept.
Speaking of frameworks... it absolutely grinds my gears how many projects are still using such an old version of Electron.
Wayland support has been upstream for quite a while, yet most of them I use are relegated to XWayland. Didn't they basically get it from Chromium?
Wayland support has been upstream for quite a while, yet most of them I use are relegated to XWayland. Didn't they basically get it from Chromium?
Speaking of Electron... vscode even intentionally ignores .config/electron-flags.conf (or it's own -flags.conf), so you must pass the ozone flags on the command line (i.e. edit the launcher, which will be replaced on next update).
There were many issues filled on vscode wrt. wayland support, hidpi, fractional scaling... and they all were closed with half-baked solution that are not really solution. It's tragic, how a project like vscode can ignore wayland and it's features for such a long time.
There were many issues filled on vscode wrt. wayland support, hidpi, fractional scaling... and they all were closed with half-baked solution that are not really solution. It's tragic, how a project like vscode can ignore wayland and it's features for such a long time.
Argh, that's frustrating. That's been my default (uninformed) state -- those flags files never seem to work for me. I override launchers all the time.
I've found some comfort by placing my edited copies in ~/.local/share/applications and informing 'fuzzel' (my launcher) of it by ensuring the parent directory is in $XDG_DATA_DIRS
As long as the file names match those in the 'system' directories, these will win.
I've found some comfort by placing my edited copies in ~/.local/share/applications and informing 'fuzzel' (my launcher) of it by ensuring the parent directory is in $XDG_DATA_DIRS
As long as the file names match those in the 'system' directories, these will win.
Depends if you use the Xserver directly. If you do, there are things like Xwayland which translates the commands to wayland.
But at some point you want to implement wayland support directly. If you use a library like qt, that may just be an update away.
It is not just display stuff. There is also libinput which handles gestures for example. These things you would have to change in your program.
But at some point you want to implement wayland support directly. If you use a library like qt, that may just be an update away.
It is not just display stuff. There is also libinput which handles gestures for example. These things you would have to change in your program.
From the OpenJDK wiki:
XWayland server provides limited capabilities for X11 desktop applications (see X11 Application Support and JDK-8269245). In order to get full support of the desktop features, we need to implement a pure Wayland client toolkit for java. Wayland architecture in many ways differs from X11, so we cannot reuse XAWT even for basic capabilities. The new toolkit should be implemented from scratch. Here are some major chunks of work: Event handling (...), Graphics devices support (...), java.awt.Robot (...), Client-side decorations for windows (...)
(That JDK is related to java.awt.Robot.createScreenCapture, and global screen capture is restricted by Wayland)
In short (and I've used this metaphor before) they've thrown away the complicated, dangerous steering wheel and provided a clear description of the steering column so that each app developer or desktop compositor (i.e. someone else/not us) can develop their own, presumably safer, steering wheel. For the functionality they tore away, apps either must use XWayland (the compatibility layer), rewrite to conform to pure Wayland, or submit a merge request for the thing they want to one of the Wayland repositories.
Of course, larger apps with lots of dependencies need every dependency to do Wayland appropriate things or have the XWayland server connect the dots. In some cases, for reasons I don't fully understand, the compatibility layer can be slow as hell.
For example, if I run OpenSCAD's AppImage (in Wayland with either an AMD GPU on a 3K 10bpp display or Nvidia GPU on a 4K 10bpp display) and type something like
The Wayland developers are few and seem to work on the things with the biggest impact to users/themselves while restricting a lot of proposed changes for security, stability, or "takes too long/doesn't make sense to us" reasons. Things like non-Intel GPU compatibility, unusual hardware, and legacy software have to rely on compatibility layers until someone else fixes issues upstream or downstream.
It's possible I misunderstand this system/organization and will gladly get schooled by anyone not blindly yelling, "Wayland works on my machine! Your problems exist not because of Wayland but because XYZ"
XWayland server provides limited capabilities for X11 desktop applications (see X11 Application Support and JDK-8269245). In order to get full support of the desktop features, we need to implement a pure Wayland client toolkit for java. Wayland architecture in many ways differs from X11, so we cannot reuse XAWT even for basic capabilities. The new toolkit should be implemented from scratch. Here are some major chunks of work: Event handling (...), Graphics devices support (...), java.awt.Robot (...), Client-side decorations for windows (...)
(That JDK is related to java.awt.Robot.createScreenCapture, and global screen capture is restricted by Wayland)
In short (and I've used this metaphor before) they've thrown away the complicated, dangerous steering wheel and provided a clear description of the steering column so that each app developer or desktop compositor (i.e. someone else/not us) can develop their own, presumably safer, steering wheel. For the functionality they tore away, apps either must use XWayland (the compatibility layer), rewrite to conform to pure Wayland, or submit a merge request for the thing they want to one of the Wayland repositories.
Of course, larger apps with lots of dependencies need every dependency to do Wayland appropriate things or have the XWayland server connect the dots. In some cases, for reasons I don't fully understand, the compatibility layer can be slow as hell.
For example, if I run OpenSCAD's AppImage (in Wayland with either an AMD GPU on a 3K 10bpp display or Nvidia GPU on a 4K 10bpp display) and type something like
cylinder([
The Wayland developers are few and seem to work on the things with the biggest impact to users/themselves while restricting a lot of proposed changes for security, stability, or "takes too long/doesn't make sense to us" reasons. Things like non-Intel GPU compatibility, unusual hardware, and legacy software have to rely on compatibility layers until someone else fixes issues upstream or downstream.
It's possible I misunderstand this system/organization and will gladly get schooled by anyone not blindly yelling, "Wayland works on my machine! Your problems exist not because of Wayland but because XYZ"
TLDR: it's being worked on, but not ready yet.
Nonetheless Jetbrains should be commended for their linux support. It's great!