[wayland-protocols] unstable: add xcursor-configuration

Submitted by Simon Ser on Oct. 18, 2018, 9:29 a.m.

Details

Message ID Zi0mV9yJaHoMRt1j2LoWWZk9vqtIOSbimGSoN9gE8GealcKDNuKgpc2s514MJ23Xb3mnodNXR_FrtGce5ZcRGaoX1gkw6af0rOng1oRCNiI=@emersion.fr
State New
Series "unstable: add xcursor-configuration"
Headers show

Commit Message

Simon Ser Oct. 18, 2018, 9:29 a.m.
Clients are responsible for loading and setting cursors. For this
purpose they often use XCursor images via the libwayland-cursor
library. However clients have no way to know the user's preferred
theme and size. This results in inconsistent cursors across
clients (e.g. cursor growing bigger when entering a surface).

This protocol fixes this issue by sending the user's XCursor
preferences to the client. It also allows for per-device cursor
configuration.

Signed-off-by: Simon Ser <contact@emersion.fr>
---
 Makefile.am                                   |   1 +
 unstable/xcursor-configuration/README         |   4 +
 .../xcursor-configuration-unstable-v1.xml     | 115 ++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 unstable/xcursor-configuration/README
 create mode 100644 unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 6394e26..7ac70ec 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,6 +18,7 @@  unstable_protocols =								\
 	unstable/idle-inhibit/idle-inhibit-unstable-v1.xml			\
 	unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml	\
 	unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
+	unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml				\
 	unstable/xdg-output/xdg-output-unstable-v1.xml				\
 	unstable/input-timestamps/input-timestamps-unstable-v1.xml	\
 	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
diff --git a/unstable/xcursor-configuration/README b/unstable/xcursor-configuration/README
new file mode 100644
index 0000000..472e3bf
--- /dev/null
+++ b/unstable/xcursor-configuration/README
@@ -0,0 +1,4 @@ 
+xcursor configuration protocol
+
+Maintainers:
+Simon Ser <contact@emersion.fr>
diff --git a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
new file mode 100644
index 0000000..b479c6f
--- /dev/null
+++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
@@ -0,0 +1,115 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="wp_xcursor_configuration_unstable_v1">
+  <copyright>
+    Copyright © 2018 Simon Ser
+
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+
+  <description summary="protocol to configure XCursor themes">
+    This protocol allows compositors to advertize XCursor configuration to
+    clients.
+
+    Once compositor configuration is received, clients are responsible for
+    loading the XCursor theme, creating wl_buffers with cursor images and
+    setting the cursor. Clients are free to ignore configuration set by this
+    protocol and use different settings: this protocol merely exposes hints.
+
+    Warning! The protocol described in this file is experimental and
+    backward incompatible changes may be made. Backward compatible changes
+    may be added together with the corresponding interface version bump.
+    Backward incompatible changes are done by bumping the version number in
+    the protocol and interface names and resetting the interface version.
+    Once the protocol is to be declared stable, the 'z' prefix and the
+    version number in the protocol and interface names are removed and the
+    interface version number is reset.
+  </description>
+
+  <interface name="zwp_xcursor_configuration_manager_v1" version="1">
+    <description summary="XCursor configuration manager">
+      A global factory interface for wp_xcursor_configuration objects.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the XCursor configuration manager object">
+        Destroy the XCursor configuration manager. This doesn't destroy objects
+        created with the manager.
+      </description>
+    </request>
+
+    <enum name="device_type">
+      <description summary="an input device type">
+        Describes input devices that have a cursor and are attached to a seat.
+      </description>
+      <entry name="pointer" value="1" summary="Pointer"/>
+      <entry name="tablet_tool" value="2" summary="Tablet tool"/>
+    </enum>
+
+    <request name="get_device_xcursor_configuration">
+      <description summary="create a wp_xcursor_configuration object for a device">
+        This creates a new wp_xcursor_configuration object for the input device
+        attached to the given seat.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_xcursor_configuration_v1"/>
+      <arg name="seat" type="object" interface="wl_seat"/>
+      <arg name="device" type="uint" enum="device_type"/>
+    </request>
+  </interface>
+
+  <interface name="zwp_xcursor_configuration_v1" version="1">
+    <description summary="XCursor configuration for a device">
+      A Xcursor configuration object describes XCursor settings for a specific
+      device.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy this object">
+        Using this request a client can tell the server that it is not going to
+        use this object anymore.
+      </description>
+    </request>
+
+    <event name="done">
+      <description summary="all information about the configuration has been sent">
+        This event is sent after all other properties of a
+        wp_xcursor_configuration have been sent.
+
+        This allows changes to the wp_xcursor_configuration properties to be
+        seen as atomic, even if they happen via multiple events.
+      </description>
+    </event>
+
+    <event name="theme">
+      <description summary="theme configuration">
+        The theme event describes XCursor theme configuration for this device.
+      </description>
+      <arg name="name" type="string" summary="theme name"/>
+      <arg name="size" type="uint" summary="theme size"/>
+    </event>
+
+    <event name="default_cursor">
+      <description summary="default cursor name">
+        The default_cursor event describes the default XCursor cursor name to be
+        used for this device.
+      </description>
+      <arg name="name" type="string" summary="default cursor name"/>
+    </event>
+  </interface>
+</protocol>

Comments

Simon Ser Oct. 30, 2018, 10:20 a.m.
Hi,

I'd like to bump this patch. Has anyone comments about this
protocol?

Thanks,

Simon
Simon Ser Dec. 4, 2018, 8:18 a.m.
Hi Johan, Pekka, Jonas,

What do you think of this protocol?

Thanks,

Simon

On Thursday, October 18, 2018 11:29 AM, Simon Ser <contact@emersion.fr> wrote:
> Clients are responsible for loading and setting cursors. For this
> purpose they often use XCursor images via the libwayland-cursor
> library. However clients have no way to know the user's preferred
> theme and size. This results in inconsistent cursors across
> clients (e.g. cursor growing bigger when entering a surface).
>
> This protocol fixes this issue by sending the user's XCursor
> preferences to the client. It also allows for per-device cursor
> configuration.
>
> Signed-off-by: Simon Ser <contact@emersion.fr>
> ---
>  Makefile.am                                   |   1 +
>  unstable/xcursor-configuration/README         |   4 +
>  .../xcursor-configuration-unstable-v1.xml     | 115 ++++++++++++++++++
>  3 files changed, 120 insertions(+)
>  create mode 100644 unstable/xcursor-configuration/README
>  create mode 100644 unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 6394e26..7ac70ec 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -18,6 +18,7 @@ unstable_protocols =								\
>  	unstable/idle-inhibit/idle-inhibit-unstable-v1.xml			\
>  	unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml	\
>  	unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
> +	unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml				\
>  	unstable/xdg-output/xdg-output-unstable-v1.xml				\
>  	unstable/input-timestamps/input-timestamps-unstable-v1.xml	\
>  	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
> diff --git a/unstable/xcursor-configuration/README b/unstable/xcursor-configuration/README
> new file mode 100644
> index 0000000..472e3bf
> --- /dev/null
> +++ b/unstable/xcursor-configuration/README
> @@ -0,0 +1,4 @@
> +xcursor configuration protocol
> +
> +Maintainers:
> +Simon Ser <contact@emersion.fr>
diff --git a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml > b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
> new file mode 100644
> index 0000000..b479c6f
> --- /dev/null
> +++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
> @@ -0,0 +1,115 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="wp_xcursor_configuration_unstable_v1">
> +  <copyright>
> +    Copyright © 2018 Simon Ser
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <description summary="protocol to configure XCursor themes">
> +    This protocol allows compositors to advertize XCursor configuration to
> +    clients.
> +
> +    Once compositor configuration is received, clients are responsible for
> +    loading the XCursor theme, creating wl_buffers with cursor images and
> +    setting the cursor. Clients are free to ignore configuration set by this
> +    protocol and use different settings: this protocol merely exposes hints.
> +
> +    Warning! The protocol described in this file is experimental and
> +    backward incompatible changes may be made. Backward compatible changes
> +    may be added together with the corresponding interface version bump.
> +    Backward incompatible changes are done by bumping the version number in
> +    the protocol and interface names and resetting the interface version.
> +    Once the protocol is to be declared stable, the 'z' prefix and the
> +    version number in the protocol and interface names are removed and the
> +    interface version number is reset.
> +  </description>
> +
> +  <interface name="zwp_xcursor_configuration_manager_v1" version="1">
> +    <description summary="XCursor configuration manager">
> +      A global factory interface for wp_xcursor_configuration objects.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy the XCursor configuration manager object">
> +        Destroy the XCursor configuration manager. This doesn't destroy objects
> +        created with the manager.
> +      </description>
> +    </request>
> +
> +    <enum name="device_type">
> +      <description summary="an input device type">
> +        Describes input devices that have a cursor and are attached to a seat.
> +      </description>
> +      <entry name="pointer" value="1" summary="Pointer"/>
> +      <entry name="tablet_tool" value="2" summary="Tablet tool"/>
> +    </enum>
> +
> +    <request name="get_device_xcursor_configuration">
> +      <description summary="create a wp_xcursor_configuration object for a device">
> +        This creates a new wp_xcursor_configuration object for the input device
> +        attached to the given seat.
> +      </description>
> +      <arg name="id" type="new_id" interface="zwp_xcursor_configuration_v1"/>
> +      <arg name="seat" type="object" interface="wl_seat"/>
> +      <arg name="device" type="uint" enum="device_type"/>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_xcursor_configuration_v1" version="1">
> +    <description summary="XCursor configuration for a device">
> +      A Xcursor configuration object describes XCursor settings for a specific
> +      device.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy this object">
> +        Using this request a client can tell the server that it is not going to
> +        use this object anymore.
> +      </description>
> +    </request>
> +
> +    <event name="done">
> +      <description summary="all information about the configuration has been sent">
> +        This event is sent after all other properties of a
> +        wp_xcursor_configuration have been sent.
> +
> +        This allows changes to the wp_xcursor_configuration properties to be
> +        seen as atomic, even if they happen via multiple events.
> +      </description>
> +    </event>
> +
> +    <event name="theme">
> +      <description summary="theme configuration">
> +        The theme event describes XCursor theme configuration for this device.
> +      </description>
> +      <arg name="name" type="string" summary="theme name"/>
> +      <arg name="size" type="uint" summary="theme size"/>
> +    </event>
> +
> +    <event name="default_cursor">
> +      <description summary="default cursor name">
> +        The default_cursor event describes the default XCursor cursor name to be
> +        used for this device.
> +      </description>
> +      <arg name="name" type="string" summary="default cursor name"/>
> +    </event>
> +  </interface>
> +</protocol>
> --
> 2.19.1
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Jonas Ådahl Dec. 10, 2018, 1:51 p.m.
There is an alternative more generic solution to this problem, and all
other related to what XSettings did in the past. If we'd end up
introducing a protocol like this, we might end up with many tiny
protocols for things previously covered by XSettings. Cursor things,
font things, and what not. Adding a new protocol for each these things
would be silly.

The generic alternative is designed with sandboxing in mind (but
of course doesn't require it in any way), and is part of
xdg-desktop-portal, the same place where the compositor agnostic
screen casting API lives (org.freedesktop.portal.ScreenCast, implemented
at least by GNOME and KDE).

It's a D-Bus API called org.freedesktop.portal.Settings[0]. The only
thing a compositor would need to do is to provide a
org.freedesktop.impl.portal.Settings implementation using whatever
settings backend might be in place.


Jonas


[0] https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml

On Tue, Dec 04, 2018 at 08:18:47AM +0000, Simon Ser wrote:
> Hi Johan, Pekka, Jonas,
> 
> What do you think of this protocol?
> 
> Thanks,
> 
> Simon
> 
> On Thursday, October 18, 2018 11:29 AM, Simon Ser <contact@emersion.fr> wrote:
> > Clients are responsible for loading and setting cursors. For this
> > purpose they often use XCursor images via the libwayland-cursor
> > library. However clients have no way to know the user's preferred
> > theme and size. This results in inconsistent cursors across
> > clients (e.g. cursor growing bigger when entering a surface).
> >
> > This protocol fixes this issue by sending the user's XCursor
> > preferences to the client. It also allows for per-device cursor
> > configuration.
> >
> > Signed-off-by: Simon Ser <contact@emersion.fr>
> > ---
> >  Makefile.am                                   |   1 +
> >  unstable/xcursor-configuration/README         |   4 +
> >  .../xcursor-configuration-unstable-v1.xml     | 115 ++++++++++++++++++
> >  3 files changed, 120 insertions(+)
> >  create mode 100644 unstable/xcursor-configuration/README
> >  create mode 100644 unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 6394e26..7ac70ec 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -18,6 +18,7 @@ unstable_protocols =								\
> >  	unstable/idle-inhibit/idle-inhibit-unstable-v1.xml			\
> >  	unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml	\
> >  	unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
> > +	unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml				\
> >  	unstable/xdg-output/xdg-output-unstable-v1.xml				\
> >  	unstable/input-timestamps/input-timestamps-unstable-v1.xml	\
> >  	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
> > diff --git a/unstable/xcursor-configuration/README b/unstable/xcursor-configuration/README
> > new file mode 100644
> > index 0000000..472e3bf
> > --- /dev/null
> > +++ b/unstable/xcursor-configuration/README
> > @@ -0,0 +1,4 @@
> > +xcursor configuration protocol
> > +
> > +Maintainers:
> > +Simon Ser <contact@emersion.fr>
> diff --git a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml > b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
> > new file mode 100644
> > index 0000000..b479c6f
> > --- /dev/null
> > +++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
> > @@ -0,0 +1,115 @@
> > +<?xml version="1.0" encoding="UTF-8"?>
> > +<protocol name="wp_xcursor_configuration_unstable_v1">
> > +  <copyright>
> > +    Copyright © 2018 Simon Ser
> > +
> > +    Permission is hereby granted, free of charge, to any person obtaining a
> > +    copy of this software and associated documentation files (the "Software"),
> > +    to deal in the Software without restriction, including without limitation
> > +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > +    and/or sell copies of the Software, and to permit persons to whom the
> > +    Software is furnished to do so, subject to the following conditions:
> > +
> > +    The above copyright notice and this permission notice (including the next
> > +    paragraph) shall be included in all copies or substantial portions of the
> > +    Software.
> > +
> > +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> > +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > +    DEALINGS IN THE SOFTWARE.
> > +  </copyright>
> > +
> > +  <description summary="protocol to configure XCursor themes">
> > +    This protocol allows compositors to advertize XCursor configuration to
> > +    clients.
> > +
> > +    Once compositor configuration is received, clients are responsible for
> > +    loading the XCursor theme, creating wl_buffers with cursor images and
> > +    setting the cursor. Clients are free to ignore configuration set by this
> > +    protocol and use different settings: this protocol merely exposes hints.
> > +
> > +    Warning! The protocol described in this file is experimental and
> > +    backward incompatible changes may be made. Backward compatible changes
> > +    may be added together with the corresponding interface version bump.
> > +    Backward incompatible changes are done by bumping the version number in
> > +    the protocol and interface names and resetting the interface version.
> > +    Once the protocol is to be declared stable, the 'z' prefix and the
> > +    version number in the protocol and interface names are removed and the
> > +    interface version number is reset.
> > +  </description>
> > +
> > +  <interface name="zwp_xcursor_configuration_manager_v1" version="1">
> > +    <description summary="XCursor configuration manager">
> > +      A global factory interface for wp_xcursor_configuration objects.
> > +    </description>
> > +
> > +    <request name="destroy" type="destructor">
> > +      <description summary="destroy the XCursor configuration manager object">
> > +        Destroy the XCursor configuration manager. This doesn't destroy objects
> > +        created with the manager.
> > +      </description>
> > +    </request>
> > +
> > +    <enum name="device_type">
> > +      <description summary="an input device type">
> > +        Describes input devices that have a cursor and are attached to a seat.
> > +      </description>
> > +      <entry name="pointer" value="1" summary="Pointer"/>
> > +      <entry name="tablet_tool" value="2" summary="Tablet tool"/>
> > +    </enum>
> > +
> > +    <request name="get_device_xcursor_configuration">
> > +      <description summary="create a wp_xcursor_configuration object for a device">
> > +        This creates a new wp_xcursor_configuration object for the input device
> > +        attached to the given seat.
> > +      </description>
> > +      <arg name="id" type="new_id" interface="zwp_xcursor_configuration_v1"/>
> > +      <arg name="seat" type="object" interface="wl_seat"/>
> > +      <arg name="device" type="uint" enum="device_type"/>
> > +    </request>
> > +  </interface>
> > +
> > +  <interface name="zwp_xcursor_configuration_v1" version="1">
> > +    <description summary="XCursor configuration for a device">
> > +      A Xcursor configuration object describes XCursor settings for a specific
> > +      device.
> > +    </description>
> > +
> > +    <request name="destroy" type="destructor">
> > +      <description summary="destroy this object">
> > +        Using this request a client can tell the server that it is not going to
> > +        use this object anymore.
> > +      </description>
> > +    </request>
> > +
> > +    <event name="done">
> > +      <description summary="all information about the configuration has been sent">
> > +        This event is sent after all other properties of a
> > +        wp_xcursor_configuration have been sent.
> > +
> > +        This allows changes to the wp_xcursor_configuration properties to be
> > +        seen as atomic, even if they happen via multiple events.
> > +      </description>
> > +    </event>
> > +
> > +    <event name="theme">
> > +      <description summary="theme configuration">
> > +        The theme event describes XCursor theme configuration for this device.
> > +      </description>
> > +      <arg name="name" type="string" summary="theme name"/>
> > +      <arg name="size" type="uint" summary="theme size"/>
> > +    </event>
> > +
> > +    <event name="default_cursor">
> > +      <description summary="default cursor name">
> > +        The default_cursor event describes the default XCursor cursor name to be
> > +        used for this device.
> > +      </description>
> > +      <arg name="name" type="string" summary="default cursor name"/>
> > +    </event>
> > +  </interface>
> > +</protocol>
> > --
> > 2.19.1
> >
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
Simon Ser Dec. 10, 2018, 2:10 p.m.
On Monday, December 10, 2018 2:51 PM, Jonas Ådahl <jadahl@gmail.com> wrote:
> There is an alternative more generic solution to this problem, and all
> other related to what XSettings did in the past. If we'd end up
> introducing a protocol like this, we might end up with many tiny
> protocols for things previously covered by XSettings. Cursor things,
> font things, and what not. Adding a new protocol for each these things
> would be silly.
>
> The generic alternative is designed with sandboxing in mind (but
> of course doesn't require it in any way), and is part of
> xdg-desktop-portal, the same place where the compositor agnostic
> screen casting API lives (org.freedesktop.portal.ScreenCast, implemented
> at least by GNOME and KDE).
>
> It's a D-Bus API called org.freedesktop.portal.Settings[0]. The only
> thing a compositor would need to do is to provide a
> org.freedesktop.impl.portal.Settings implementation using whatever
> settings backend might be in place.

Hi,

Unfortunately I don't think D-Bus is a good solution here. Here are a few
reasons why:

* Not all clients use D-Bus. Adding support for your API would mean adding a lot
  of code and new dependencies to many clients.
* The idea would be to add support to libwayland-cursor so that many users can
  benefit from the protocol. I don't think firing up a D-Bus connection in
  libwayland-cursor as a viable solution.
* Multi-seat support would be kind of alien.

What do you think?

Thanks,

Simon

>
> Jonas
>
>
> [0] https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml
Jonas Ådahl Dec. 10, 2018, 2:24 p.m.
On Mon, Dec 10, 2018 at 02:10:30PM +0000, Simon Ser wrote:
> On Monday, December 10, 2018 2:51 PM, Jonas Ådahl <jadahl@gmail.com> wrote:
> > There is an alternative more generic solution to this problem, and all
> > other related to what XSettings did in the past. If we'd end up
> > introducing a protocol like this, we might end up with many tiny
> > protocols for things previously covered by XSettings. Cursor things,
> > font things, and what not. Adding a new protocol for each these things
> > would be silly.
> >
> > The generic alternative is designed with sandboxing in mind (but
> > of course doesn't require it in any way), and is part of
> > xdg-desktop-portal, the same place where the compositor agnostic
> > screen casting API lives (org.freedesktop.portal.ScreenCast, implemented
> > at least by GNOME and KDE).
> >
> > It's a D-Bus API called org.freedesktop.portal.Settings[0]. The only
> > thing a compositor would need to do is to provide a
> > org.freedesktop.impl.portal.Settings implementation using whatever
> > settings backend might be in place.
> 
> Hi,
> 
> Unfortunately I don't think D-Bus is a good solution here. Here are a few
> reasons why:
> 
> * Not all clients use D-Bus. Adding support for your API would mean adding a lot
>   of code and new dependencies to many clients.

This reason comes up everytime D-Bus is mentioned, and I think it's
somewhat counter productive; I don't think this is a problem clients
should try to avoid so hard. D-Bus is more or less the universal IPC on
Linux, is used quite extensively to allow sandboxed client to
communicate with the outside world, and is almost guaranteed to be
available everywhere.

> * The idea would be to add support to libwayland-cursor so that many users can
>   benefit from the protocol. I don't think firing up a D-Bus connection in
>   libwayland-cursor as a viable solution.

Well, we could still have applications feed settings into it. It's not
tha complex to do that, and the addition to libwayland-cursor that is
arguably more complicated could cover the server side cursor buffer
loading that was talked about before.

> * Multi-seat support would be kind of alien.

Can at least be investigated how multi seat should be achieved before
being dismissed as being alien like. I can open issues for that if you'd
there is interest.


Jonas

> 
> What do you think?
> 
> Thanks,
> 
> Simon
> 
> >
> > Jonas
> >
> >
> > [0] https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml
Drew DeVault Dec. 10, 2018, 5:09 p.m.
On 2018-12-10  3:24 PM, Jonas Ådahl wrote:
> This reason comes up everytime D-Bus is mentioned, and I think it's
> somewhat counter productive; I don't think this is a problem clients
> should try to avoid so hard. D-Bus is more or less the universal IPC on
> Linux, is used quite extensively to allow sandboxed client to
> communicate with the outside world, and is almost guaranteed to be
> available everywhere.

Nothing about Wayland limits us to Linux. We try to think more broadly,
wlroots supports FreeBSD for example.

Even without that, it's just about making the right design decisions.
The Wayland protocol is used to communicate about the cursor, and it
will be rendered by the compositor. The client and compositor already
speak Wayland to each other. To me, the ownership over this information
clearly lies in this relationship and using side-channels to communicate
this information is a bad design.