Hacker News Reader

Comment by roenxi | Hacker News Reader

Wayland represents an interesting and possibly classic software situation - a beautiful standard has been developed. It blocks the user from using a screenshot application in the name of security.

Now when the standard gets rolled out kludge will be developed to allow users to still take screenshots. The beauty of the standard will be compromised or everyone will spend a bunch of time pretending the kludge isn't de-facto part of the standard.

Wayland's model of user security was a mistake if the goal was getting typical users to use it. It isn't secure, it just means screenshots will be done with a kludge. I think literally everyone I know who owns a computing device (I'm counting phones and tablets) wants to be able to take screen captures to show people things.

View on HN

Taking your example of screenshots... I don't think there's an 'official'/defacto Wayland protocol for that. Under GNOME Shell you can use the org.gnome.Shell.Screenshot dbus API, but under KDE you presumably have to use something else. It is pretty grim.

All major distros seem to have agreed on Flatpak/Freedesktop Portal dbus APIs. For eg, for screenshot :

https://docs.flatpak.org/en/latest/portal-api-reference.html...

There are still apps using legacy gnome/kde specific APIs, but, from what I understand, in the future Flatpak APIs are becoming the defacto standard

These are dbus APIs though, not wayland protocol specifications that you can call with libwayland's RPC mechanism.

On the one hand this means you can support both X11 and Wayland with a single API from a client perspective, on the other you have to use DBus, which is horrendous to use (especially from statically typed languages).

It also doesn't seem to work on my XFCE/X11 desktop, which shows what fragmentation we have now.

> DBus, which is horrendous [from] statically typed languages

Could you explain this? In my experience DBus provides you with a schema, the exposed DBus interface describes the callable methods, their arguments and types, readable properties, and signals.

Just like with SQL it's useful to create a layer that takes advantage of the statically typed powers of the language.

Usually there are tools that use introspection (or the XML introspection data) to generate "types" (ie. this layer).

https://crates.io/crates/dbus-codegen

Yes exactly, it's always a big debate every time a new features is needed whereas it should be Wayland protocol or Dbus.

Gnome people push for everything Dbus, and many Wayland dev prefer to standardize over Wayland protocol.

It's kinda sad that the APIs are fragmented over two IPC solutions (unlike for eg on Android where everything goes through Binder IPC).

I think the overall the idea is : if it requires permission/sandbox -> Dbus, otherwise Wayland . But in practice there is a lot of disagreements.

Not all statically typed languages. Using it in QT is great, and using it in GTK in C is not more difficult than showing a window. I also recently came across zbus in rust (https://docs.rs/zbus/1.8.0/zbus/) and it looks like it’s similar dynamically typed languages. I’ve also heard good things about the Systemd implementation. In all of these situations, it’s far easier to use DBus than another Wayland protocol.

Pretty grim, heh

Context: https://wayland.emersion.fr/grim/

I use grim with sway / wayland and it works great, much better than scrot on X (which always leaves strange visual artifacts on the image when using rectangular selection).

Here's my key binding config from sway:

Reply on news.ycombinator.com