[PATCH wayland-protocols] unstable: add xcursor-configuration
ovdev at fratti.ch
Mon Jan 27 19:59:40 UTC 2020
I am a developer hoping to work more with Wayland in the future, and would
like it if you could clarify a few things regarding your response.
>D-Bus is more or less the universal IPC on Linux
However, I am unable to find D-Bus in the Linux source tree. I know it has
been proposed for inclusion into the Linux kernel, but was rejected for issues
regarding its design. As far as I can tell D-Bus is purely a userspace
abstraction on top of standard Linux IPC functionality, much like Wayland is
I'm assuming you don't mean "Linux" as in "The Linux Desktop", as I believe
GNOME's position is that there is no Linux platform. If GNOME's view on the
matter has changed, please correct me.
If you meant that it is the most popular userspace IPC mechanism on platforms
running a Linux kernel, then you'd be mistaken too, as that would be Binder. I
think if we went down the road of popular IPC mechanisms that aren't Wayland,
we should consider Binder as a real alternative, since it is more popular than
D-Bus and of a more modern design.
>and is almost guaranteed to be available everywhere.
I think there are more Wayland systems not running D-Bus than there are
Wayland systems not running Wayland. I also believe there are more Wayland
clients that do not use D-Bus but use Wayland. It seems like an odd design
decision to me to require all Wayland clients that wish to make use of system
mouse cursor themes to also require to pull some D-Bus client library into
>If we'd end up introducing a protocol like this, we might end up with many
tiny protocols for things previously covered by XSettings.
This is worded like it's a bad design decision, but I do not see the issue.
OpenGL's ARB extension mechanism works like this and has been working so well
most recent OpenGL revisions have simply ratified generally useful extensions.
Wayland has an extension mechanism, and both clients and compositors may wish
to implement only a subset of all extensions. Is a second IPC mechanism with
another specification for doing routine desktop awareness really required?
>It's a D-Bus API called org.freedesktop.portal.Settings
Is there a particular reason as to why D-Bus was chosen? To me it looks like
D-Bus is a legacy protocol with technical debt that is now being worked around
in newer implementations thereof. Wayland is a fairly recent protocol
achieving the same purpose in this case. I assume Wayland wasn't designed
around D-Bus due to shortcomings in D-Bus, so it appears very strange to me to
bring D-Bus back into the mix when it can be avoided.
More information about the wayland-devel