Wayland Support for IntelliJ-Based IDEs

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

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.

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"

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.

Nonetheless Jetbrains should be commended for their linux support. It's great!