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

[Simon Ser]

Hi Michael,

Thanks for you comments! Replies below.

On Sunday, October 14, 2018 4:05 AM, Michael Arnold <myk321 at gmail.com> wrote:
> 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?

You are right about the "setup" sequence. The "teardown" sequence is very
simple: since the Wayland protocol works with objects, when you send a request
on an object, the object itself is an implicit parameter to the request (just
like in object-oriented programming languages). The same applies to events.

That means the "theme" and "default_cursor" events are associated with the
configuration. The destroy requests are associated with either the manager or
the configuration.

The full sequence could look like this for the client:

-> config = manager.get_xcursor_configuration_seat(seat)
config.theme("Adwaita", 24)
config.default_cursor("left_ptr")
config.done()
[use the config, run the app]
-> config.destroy()
-> manager.destroy()

> 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?

Yeah. I've added this text for the next version to make it more clear:

    The theme event is sent after creating a wp_xcursor_configuration
    (see wp_xcursor_configuration_manager) and whenever the theme
    configuration changes.

(Same for the default_cursor event)

> * Why are event 'theme' and event 'default_cursor' two separate events and not
>   handled by one event with 3 attributes?

It's just to clearly make the difference between these two categories of
arguments.

> * Is 'theme' a good name for an event and not something like 'xcursor_theme'?
> * Is that implied by the context?

"xcursor" is already in the interface name, I don't think it's necessary to add
it one more time.

> * 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 think it would be enough to just send "default". This is what
libwayland-cursor uses when the theme name is NULL. Is it really necessary to
make the "theme" and "default_cursor" events optional?

> * 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?

Right.

> * 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?

The use-case is to e.g. set a tablet tool cursor to be a cross, so you can have
both a normal pointer for you mouse/touchpad and a cross pointer for your tablet
device. One could also use an alternative default cursor to be able to keep the
same theme for two seats but to be able to tell the difference between those
(e.g. by using left_ptr for one and right_ptr for the other).

This protocol allows things that aren't possible with the XCursor library, such
as setting a default cursor, having per-seat configuration and allowing live
cursor updates.

> * 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?

I think those are out-of-scope for this protocol. Actually both of these
features could be implemented in the compositor directly, clients don't need to
know about this.