[PATCH wayland-protocols] unstable: add xcursor-configuration

[ovdev at fratti.ch]

Hello Jonas,

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.

You wrote:

>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 
too.

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 
their application.

>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[0]

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.