←back to thread

345 points splitbrain | 2 comments | | HN request time: 0s | source
Show context
OsrsNeedsf2P ◴[] No.41837682[source]
I love how simple this is- Barely 100 lines or C++ (ignoring comments). That's one thing that makes me prefer X11 over Wayland.
replies(8): >>41837906 #>>41838181 #>>41838339 #>>41838393 #>>41838489 #>>41838500 #>>41838693 #>>41844644 #
jchw ◴[] No.41838393[source]
This certainly is an elegant X.org party trick that can't be done easily in almost any other windowing system: creating a virtual Xrandr display that overlaps with existing physical displays. It's slightly awkward since if it exits outside of sigint it will leave a virtual output and no overlay window but that's a pretty minor issue. (All of that having been said, I would strongly advise to not over-index on SLoC as a measure of quality or elegance.)

This flat-out can't be done in Wayland. Though all is not lost, you might not need this at all in Wayland. The standard way to capture the screen from an unprivileged process in Wayland is through desktop portals, and at least KDE supports a wide variety of different capture options including capturing a rectangle of the screen. I haven't tried, but I suspect this is even true when running X.org applications, thanks to XWaylandVideoBridge.

I am not really thrilled about D-Bus stuff everywhere, but it is nice that you can pretty much override any screen capture behavior you want by changing the org.freedesktop.impl.portal.ScreenCast implementation: I think that's actually a step in a better direction versus having every application implement its own functionality for selecting capture targets.

replies(1): >>41840134 #
rnhmjoj ◴[] No.41840134[source]
To me it's quite sad that for a lot of things, the "standard" way of doing something is not actually part of the standard (XDG portals, third party protocols, etc.). Yes, X.org is old, bloated, unmaintainable and whathever, but at least every desktop environment used the same X server implementation and the same tools worked everywhere.

Besides the duplication of efforts in implementing the same stuff over and over, now someone developing somewhat non-trivial programs needs to be aware of the differences in supported features and non-standard extensions in all desktops, for example [1].

[1]: https://wayland.app/protocols/cursor-shape-v1#compositor-sup...

replies(1): >>41840803 #
1. jchw ◴[] No.41840803{3}[source]
I think Wayland had made some mistakes, no doubt. Cursor shape just should've been part of the protocol. Wayland has its fair share of misfires.

That said, I understand what they were going for. They really wanted to make the compositor as small and simple as possible, so for example you would just use libwayland-cursor instead of bothering with cursors yourself. However there are a lot of ways libwayland-cursor worked out poorly... Not everyone agreed on how scaling should work, GTK4 ditched it for performance reasons, and overall it's just inconvenient for a lot of cases (languages other than C, sandboxing, etc.) And to make matters even worse, in practice every compositor needed to load and handle XCursor themes anyways...

That said, I think that it's okay if Wayland doesn't own the majority of the Linux desktop stack the way X11 did. It's fine for compositors and their helpers to implement protocols from other projects, too. That way Wayland can be more applicable to graphical machines other than desktops without bringing unnecessary baggage. It'll always have trade-offs, of course, but I think it's far from the end of the world.

replies(1): >>41846524 #
2. yxhuvud ◴[] No.41846524[source]
re cursors: There is a replacement/amendment protocol for cursor handling coming though I don't know the current status of it. It seemed a lot easier to work with for the vast majority of cases.