I'm confused with Wayland compositors.

[-]

daniellefore@reddit

Realistically you should be using a well-supported toolkit like GTK or Qt and distributing your app as a Flatpak using Portals which will abstract all of that away for you and you don’t have to worry about it

Reply

[-]

apina3@reddit

Oh shit, you're that crazy communist transgender woman

Reply

[-]

PureTryOut@reddit

Well building your app to be shipped purely through Flatpak is of course not necessary, it can be distributed through the "classical" package managers just fine without suddenly breaking on Wayland. Otherwise yes, it should use a well-supported toolkit and stuff should work just fine out of the box. And for toolkits that aren't updated yet to work on Wayland (I'm sure there are some) XWayland will remain an option for quite a while, but I really wouldn't recommend using those.

Reply

[-]

daniellefore@reddit

Yes but building for Flatpak’s sandbox will expose obvious issues and encourages the use of Portals which may be required for certain features on Wayland like screen sharing. There’s really not a good reason imo not to be building your graphical app for Flatpak. It can only help

Reply

[-]

zocker_160@reddit

>There’s really not a good reason imo not to be building your graphical app for Flatpak Yes except you need access to hidraw or need to place udev rules for special devices or want to install a systemd service or want to request a password from KeePassXC or need access to GPG keys or need access to system libraries inside the blacklisted folders or or or. There are no good reasons sure.

Reply

[-]

PureTryOut@reddit

I agree that it's better to make your app compatible with Flatpak, but it's really not a requirement for Wayland compatibility, which is what OP asked about. If you want screen sharing on Wayland you need to use a portal anyway, no matter if you use Flatpak or not. And if you only intend to have your application be shipped through traditional package managers then it might save a little bit of work not caring about it (although I wouldn't recommend that).

Reply

[-]

LtWorf_@reddit

You mean via a .tar.gz with a configure and a makefile in it?

Reply

[-]

Conan_Kudo@reddit

When it comes to Wayland for most applications, you don't generally need to worry about it unless you're trying to something with the graphical environment itself. _That's_ when the differences matter.

Reply

[-]

LvS@reddit

> an app tested on a single Xorg DE will works on any other Xorg DE hahahahahahahahahahahahaha *breathe* hahahahahahahahahahahahaha Oh no, this wm doesn't come with a compositing manager, so rounded corners will now be black instead of round. What, the wm does want us to draw shadows? Not draw shadows? Draw shadows sometimes? Oh, and it communicates that differently than the other ones? Oh, frame sync isn't even standardized on X? The default way how eveyr platform does compositing is a random shitshow? Oh shit, which buttons does this WM expect? And which ones does it even support? Wait, this one expects buttons it doesn't support? Who wrote a WM that wants minimize buttons but can't minimize? Oh god, did some wm screw up minimizing and iconifying again? And now somebody switched WMs at runtime and the new WM obviously supports a different combination of features.

Reply

[-]

linuxguy123@reddit

All of those seem to be issues with CSDs.

Reply

[-]

natermer@reddit

X WMs seem to "just work" because of a lot of work to make them work. Back before things like EWMH and a tremendous amount of work on the part of widget developers you couldn't even do things like run KDE apps on Gnome and visa versa. Lots of the 'standards' that make things work are just a great big pile of hacks that people have built up over the decades. It gets even worse when you throw things like "network transparency" into the mix... which is not transparent at all. Several X11 extensions don't work over the network and standard things like working sound or hardware acceleration are a alien concept to remote X11 clients. And it gets even more terrible when you start trying to get X11 working on anything other then the standard Xorg xfree86 xserver. Like Xorg's xwin, kdrive, darwin, xnest DDXes. Luckily the rest of the world has long since abandoned caring about X11 on their workstations since for about 20-25 years now Windows has had massively superior remote desktop application support. So nobody really cares about compatibility between X11 servers anymore, well except for XWayland.

Reply

[-]

LvS@reddit

Transparency is an issue with every riced terminal. Drawing shadows is relevant for menus. Frame sync isn't even related to decorations. Buttons have keyboard shortcuts and you need to make sure your app doesn't use those. Minimizing vs iconifying is not about decorations either. So while all of those affect CSD, there's always something else that also needs it.

Reply

[-]

NIL_VALUE@reddit

If you're developing a proper "app" then what u/daniellefore said is what you should do. However if you're studying the underlying protocol or you just want to roll your own toolkit, then go look up the Wayland spec, as there is standardization. Every Wayland compositor has to implement the spec otherwise it wouldn't be a Wayland compositor; usually what happens is that then the specific compositors add non-official extensions **on top** of the spec for things they think are missing from it. So in this case you should just not use the compositor specific bits and your program would work in them all

Reply

I'm confused with Wayland compositors.

Reply to Post

13 Comments

daniellefore@reddit

apina3@reddit

PureTryOut@reddit

daniellefore@reddit

zocker_160@reddit

PureTryOut@reddit

LtWorf_@reddit

Conan_Kudo@reddit

LvS@reddit

linuxguy123@reddit

natermer@reddit

LvS@reddit

NIL_VALUE@reddit