Adopt GTK3 CSS cursor names

[dvogel]

Problem: GTK4 will drop numeric cursor support.
Solution: Adopt GTK3 CSS cursor convention.

---

I've been working on GTK4 support. GTK3 began the transition to CSS styling for mouse cursors. GTK4 drops almost all X11-specific constructs, including the numeric X cursors. GTK3 began this transition by supporting CSS names for mouse cursors. This PR adopts that convention as a precursor to GTK4 support.

[dvogel]

These choices are best considered relative to the mshape_ids array above. It seems we'll have to make some tough choices because GTK no longer supports all of the shapes documented under mouseshape. This PR is still in draft mode because I have not updated that documentation to explain which shapes are supported under GTK. I will do so once we agree on the choices in this list.

[chrisbra]

Thanks for working on that. I think that makes sense. Do I understand correctly, that this should not break anything on GUI (GTK3) Vim?

[dvogel]

Thanks for working on that. I think that makes sense. Do I understand correctly, that this should not break anything on GUI (GTK3) Vim?

No errors or crashes will occur. However it is not backward compatible. Users who currently use numeric cursor shape IDs or any of the following vim shape names will see different icons. The underlying issue is that gdk_cursor_new_from_name supports fewer cursor shapes than gdk_cursor_new/GdkCursorType does. The latter is based on X11 conventions that are being deprecated by GTK.

• hand1
• hand2
• pencil
• rightup-arrow
• up-arrow

[chrisbra]

Okay, so it looks like we will have those 'mouseshapes':

(System is w for Windows and x for X11, perhaps we should add a G for GTK).

System	Vim Name	GDK/CSS Name	Desc
w x	arrow	default	Normal mouse pointer
w x	blank	blank	no pointer at all (use with care!)
x	hand1	pointer	black hand
x	hand2	pointer	white hand
x	pencil	pointer	what you write with
x	question	help	big ?
x	crosshair	crosshair	like a big thin +
w x	updown	ns-resize	up-down sizing arrows
w x	leftright	ew-resize	left-right sizing arrows
w x	no	not-allowed	The system's usual 'no input' pointer
x	udsizing	ns-resize	indicates up-down resizing
x	lrsizing	ew-resize	indicates left-right resizing

Missing:

System	Vim Name	GDK Name	Desc
w x	busy		The system's usual busy pointer
w x	beam		I-beam
x	rightup-arrow		arrow pointing right-up
w x	up-arrow		arrow pointing up
x			any X11 pointer number (see X11/cursorfont.h)

I am a bit surprised we don't have beam and busy. But when this is no longer supported by the underlying library :/

Currently the help states also this:

Any modes not specified or shapes not available use the normal mouse pointer.

So it seems more or less okay? Can we keep the current cursor shapes when we still use GTK2/3 UI?

[dvogel]

We will have support for the vim names beam and busy. They translate to the CSS names text and progress. Here's a couple of screenshots showing how those look on my screen with vim -g --clean -U /dev/null. Please ignore the cursor size. It appears comically large here because the (a) it is configured to be extra large by preference and (b) the default font size is very small.

I like the idea of adding a g for GTK to that table. I'll incorporate that into my next update.

Regarding when to adopt this, I don't have a firm preference. I wanted to start on this because it is coming eventually and would take some discussion. If it is best to delay this until GTK4 that is fine with me. I think one argument for adopting this in GTK3 sooner rather than later relates to GTK2 support. I don't yet have a firm grasp on how hard it will be to maintain support for all of GTK2/3/4. Whatever the absolute effort required, on a relative basis it would be considerably easier to support any two versions of GTK at once. This seems to have been the approach so far. If we decide that we will support only GTK3/4 in vim10 then I think there's two ways to approach that:

• We could decide that vim with GTK is meant to lean into all of the GTK-isms, including only supporting the X11-isms that have direct Wayland couterparts. This would make Motif the primary means of accessing X11-isms.
• We could instead decide that vim's GTK3 integration will opt into all of the X11-isms to allow people to maximize their use of X11 until GTK5 support is added. This would mean the only way for gvim users to maximize their use of Wayland would be to use GTK4.

The first option would argue for merging this now. The second option would argue for folding this into the much larger effort to support GTK4.

We currently have a kludge that shunts vim users into X11 even with GTK3 unless they explicitly opt into Wayland. I think that was good when it was added but eventually this will have to be removed.

#if GTK_CHECK_VERSION(3,10,0)
    // Vim currently assumes that Gtk means X11, so it cannot use native Gtk
    // support for other backends such as Wayland.
    //
    // Use an environment variable to enable unfinished Wayland support.
    if (getenv("GVIM_ENABLE_WAYLAND") == NULL)
	gdk_set_allowed_backends("x11");
#endif