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

[Pekka Paalanen]

On Tue, 11 Jun 2013 12:27:43 -0700
Elvis Lee(이광웅) <kwangwoong.lee at lge.com> wrote:

> Thanks for your comments. It's really helpful.
> I almost understood the Wayland designs for cursor.
> Basically, I respect the designs. And possibly my issue can be
> handled with dynamic-switching of wayland-cursor. But I'm not sure
> yet that it's good approach.
> 
> Here goes *real* use-case, expecting to find a better way.
> 
> There is a compositor which includes UXs like a *launcher*.
> From this point, I think it’s going to different way with the Wayland
> design. :( As I know, it’s for performance since the UXs have lots of
> hovering, animations and images. For those UXs, compositor should
> have *system cursor*. Actually that's not problem yet. Because
> focuses without client can be handled well on compositor.

Ok, but I still don't see the relevance of a system cursor, why do
those UI elements want a system cursor instead of setting the same
cursor image on their own.

I heard rumours that you might have some hardware restriction that
makes updating a cursor image expensive. Is there any truth to that?

> Also, for system, there is a setting app which can change theme of
> system cursor.

This is an important point. You have to somehow communicate to all
clients, that the default cursor theme has changed, and they need to
reload their cursors. This is what we do not have yet.

> For example, we can think about SDL game app.
> It will use custom cursor for specific game scene.
> But it want to use same cursor with system UXs for scenes like a menu
> selection. Usually it uses a API to store system cursor. -
> SDL_GetCursor -- Get the currently active mouse cursor. But there is
> no way to support this API on Wayland. Currently it's not important
> to support this API. Because there is no guarantee for that current
> cursor is same with system cursor.

This I don't understand. SDL_GetCursor returns the cursor that you with
SDL_SetCursor or libSDL itself automatically last set, does it not?
On Wayland, libSDL internally would just use libwayland-cursor to get
the default cursor, and automatically use it.

If a client wants to use the "system" cursor theme, it will simply load
the cursor theme called "default" via libwayland-cursor.

> In case of any app having mouse focus, it will handle pointer_enter.
> If the app wants to use same cursor with system UX's *current* one,
> it should know about what it is. Because the system cursor is
> configurable.

Yeah, here's your point: you want to change the default cursor theme at
runtime, dynamically.

If the default cursor theme stayed the same during a session lifetime,
then you would simply load the theme "default" once at the start of
each application, and be done with it.

> Now I return to the origin point.
> According to Wayland design, there might be no way except supporting
> dynamic-switching for theme of wayland-cursor. Can I find another
> approach?

Right, knowing the default cursor theme is not a problem in itself. The
problem is that the default (or system) cursor theme changes.

This requires a Wayland protocol extension, that will announce the name
of the new cursor theme as it changes, I believe.

Or, a completely different mechanism, that not only stores settings,
but announces their changes runtime. I think both Gnome and KDE or Qt
have their own things.

Now I at least understand what you really want. :-)

What would be the preferred solution, I cannot say. The first question
is, do you need the solution in Wayland upstream, or would you be happy
with whatever solution you can make up for the project at hand?

I guess the question for the Wayland developer community is, do we want
such cursor theme settings in the shell protocol, or is that something
that should be left for DEs to solve in their own configuration systems?


Thanks,
pq