5 ms·

Wayland Support for IntelliJ-Based IDEs

28 points by dcgudeman 3y ago

robswc 3y ago
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.
- bravetraveler 3y ago
  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
  - robswc 3y ago
    I'll have to look into it. I switched back and haven't attempted to switch again but it really was so nice.
    - bravetraveler 3y ago
      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
TurningCanadian 3y ago
TLDR: it's being worked on, but not ready yet.
- gumballindie 3y ago
  Nonetheless Jetbrains should be commended for their linux support. It's great!
FirmwareBurner 3y ago
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?
- deutschepost 3y ago
  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.
- PennRobotics 3y ago
  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 cylinder([ it takes about a second to type but at least three seconds to fully appear in the editor. Switching to X instantly resolves the issue. OpenSCAD is Qt and has a handful of other dependencies that I guess are also not as actively developed, plus the official release has lagged the nightly for the past 3 years or so despite active development. 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"

28 points by dcgudeman 3y ago

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.

bravetraveler 3y ago
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
- robswc 3y ago
  I'll have to look into it. I switched back and haven't attempted to switch again but it really was so nice.
  - bravetraveler 3y ago
    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

TurningCanadian 3y ago

TLDR: it's being worked on, but not ready yet.

gumballindie 3y ago
Nonetheless Jetbrains should be commended for their linux support. It's great!

FirmwareBurner 3y ago

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?

deutschepost 3y ago
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.
PennRobotics 3y ago
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 cylinder([ it takes about a second to type but at least three seconds to fully appear in the editor. Switching to X instantly resolves the issue. OpenSCAD is Qt and has a handful of other dependencies that I guess are also not as actively developed, plus the official release has lagged the nightly for the past 3 years or so despite active development. 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"