[PATCH RFC wayland-protocols] unstable: add xcursor-configuration
Michael Arnold
myk321 at gmail.com
Sun Oct 14 02:05:54 UTC 2018
Hi,
Sean, this looks great. In the hope that basic questions help, I've
recorded my comments below - apologies if these questions reflection of my
lack of understanding.
My understanding:
Step 1: When an application loads, the application will check which
protocol extensions are common between the application and compositor. If
the zwp_xcursor_configuration_manager is common to both the application and
the compositor and the client is able to interact with the XCursor library
then the application will initiate the following conversation with the
compositor to retrieve the xcursor configuration information. Client ->
Compositor
request=get_xcursor_configuration_seat
id=123
interface=zwp_xcursor_configuration_v1
seat=1
Compositor -> Client
event=theme
name="Adwaita" //Theme name
size=24 //Theme size
Compositor -> Client
event=default_cursor
name:"abc" //default cursor name
Compositor -> Client
event=done
Step 2: Based on the information received from the compositor the
application will use the XCursor library to load / display the appropriate
mouse cursors.
Step 3: When the application exists, if the application has made use of the
zwp_xcursor_configuration_v1 extension then the application will initiate
the following conversation with the compositor:
* I get stuck here - there are two destructor requests both called
'destroy' - are they both required?
* Neither of the 'destroy' requests have an id for the application to
identify to the compositor what should be destroyed? I assume that the
destroy request is associated with the get_xcursor_configuration_seat
request, so in-principle an application can destroy the seat information if
the application itself is multi-seat aware - is that right? In which case
is a seat parameter required for the destroy request?
Questions:
* What happens if a user changes the cursor theme / size / default cursor
while the application is running? I assume that the compositor must create
the 'theme', 'default_cursor' and 'done' events and the application must
update the cursor accordingly?
* Why are event 'theme' and event 'default_cursor' two separate events and
not handled by one event with 3 attributes?
* Is 'theme' a good name for an event and not something like
'xcursor_theme'? Is that implied by the context?
* It is implied on the XCursor man page that a theme may not be set. In
this case does the compositor return an empty theme 'name' on the 'theme'
event? Or is the 'name' set to 'default' if no theme is set?
* I see that XCursor interface has (
https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml):
int XcursorGetDefaultSize (Display *dpy) //Gets the default cursor
size.
char *XcursorGetTheme (Display *dpy) //Gets the current theme
name.
I see that Display* is defined in Xlib.h and looks like it gets populated
when the application connects to an X server. So I assume that the 'theme'
event is required because the application can't interact with the XCursor
library to get this information directly, because it does not have an
XServer Display connection?
* For the XCursor interface (
https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml), I can't
see where the default_cursor name is used. Likewise I can't see a setting
for default_cursor name under Gnome settings or in dconf editor. What is
the thinking behind the default_cursor event? Is this really the XCursor
'shape' parameter that the application needs to convert to an unsigned int?
* I see that Gnome settings has some interesting settings that are not
included in XCursor like:
- Is the primary button the left or right button?
- What is the mouse cursor speed?
I assume we'll pick those up in the more advanced protocol?
Kind regards,
Michael
On Sat, Oct 13, 2018 at 1:41 AM Simon Ser <contact at 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-seat cursor
> configuration.
>
> Signed-off-by: Simon Ser <contact at emersion.fr>
> ---
>
> This is a draft of the XCursor configuration protocol. It's pretty
> simple.
>
> It still doesn't allow to configure differently wl_pointer's cursor
> and the tablet tool's cursor. Maybe this can be done with an enum
> and a new get_xcursor_configuration_seat argument?
>
> Comments welcome!
>
> unstable/xcursor-configuration/README | 4 +
> .../xcursor-configuration-unstable-v1.xml | 105 ++++++++++++++++++
> 2 files changed, 109 insertions(+)
> create mode 100644 unstable/xcursor-configuration/README
> create mode 100644
> unstable/xcursor-configuration/xcursor-configuration-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 at 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..9d9d840
> --- /dev/null
> +++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml
> @@ -0,0 +1,105 @@
> +<?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.
> +
> + 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>
> +
> + <request name="get_xcursor_configuration_seat">
> + <description summary="create a wp_xcursor_configuration object for
> a seat">
> + This creates a new wp_xcursor_configuration object for the given
> + wl_seat.
> + </description>
> + <arg name="id" type="new_id"
> interface="zwp_xcursor_configuration_v1"/>
> + <arg name="seat" type="object" interface="wl_seat"/>
> + </request>
> + </interface>
> +
> + <interface name="zwp_xcursor_configuration_v1" version="1">
> + <description summary="XCursor configuration for a seat">
> + A Xcursor configuration seat object describes XCursor settings for a
> + specific seat.
> + </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
> seat.
> + </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 seat.
> + </description>
> + <arg name="name" type="string" summary="default cursor name"/>
> + </event>
> + </interface>
> +</protocol>
> --
> 2.19.1
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181014/3fe10b37/attachment.html>
More information about the wayland-devel
mailing list