The way to use system cursor and custom(client) cursor

Pekka Paalanen ppaalanen at gmail.com
Mon Jun 10 10:16:32 PDT 2013


On Mon, 10 Jun 2013 09:31:22 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On 06/09/2013 11:02 PM, Pekka Paalanen wrote:
> 
> >> Is this approach possible? I want to listen your opinions.
> >
> > Hi Elvis,
> >
> > do I understand right, that you would like to add the concept of a
> > system cursor?
> >
> > I guess it would be possible, but why?
> >
> > It seems the system cursor you propose would be one arbitrary cursor
> > without any meaning. When and why would applications ever want to use
> > it?
> >
> > The compositor usually cannot, and there is no need to, switch to a
> > system cursor on its own, so it would always be requested by a client.
> > I can understand applications wanting a specific cursor, or no cursor,
> > but what would be the purpose of a system cursor?
> >
> > If you also consider cursor themes, the system cursor would be from one
> > theme. An application using a system cursor would need to use the same
> > theme for its other cursors to look consistent.
> >
> > We already have libwayland-cursor to help you load a cursor theme, so
> > using a proper cursor should not be too hard.
> 
> If a client does nothing after an enter event it will get the system 
> cursor.

That would cause cursor flicker. Btw this is a suggestion, right?
Because this is not what the current implementation does. In the
current Wayland protocol, the cursor is undefined on enter, and in
practice the cursor is what the previous client set it to, to avoid
flicker.

Flicker is worse than possibly delaying the cursor change by a
frame or two.

> If they change the cursor they cannot return to the system 
> cursor without either replicating a lot of implementation (possibly 
> incorrectly) or by waiting for the user to move the mouse to point at 
> the desktop and re-enter. This seems wrong to me. It should always be 
> possible for the client to put themselves into a default state.

Are you talking about the current implementation in Weston, or is this
a suggestion? Currently there is no such thing as a system
cursor, nor a default cursor.

And to avoid the replication, we already have libwayland-cursor.

> Having no buffer act the same as "a buffer that is entirely transparent" 
> might be a good idea for all surfaces.

Eh, no.

- pq


More information about the wayland-devel mailing list