This cursor is active when the widget has the mouse focus. You know,
like textboxes are wont to do anywhere else. Took long enough, although
there was an interaction issue with tooltips fixed in the previous
commit.
I still need to figure out how to make this work with GUI1 textboxes
(e.g. in-game console).
The colour version of the cursor was kindly provided by LordBob, and the
B&W version is my own.
Currently it's the gui2::window class' responsibility, by inheriting
from cursor::setter (yes) and offering absolutely no way to control it.
Unfortunately, it turns out that this can cause issues with tooltips
resetting the cursor at unexpected times when they get
displayed/hidden while having widgets change the cursor depending on
whether they have the mouse focus or not.
Right now the only modeless dialog we have is the tooltip dialog, and
really there's no reason to say that modeless dialogs should have the
ability to reset the cursor without explicitly asking for it. As for
modal dialogs... I don't entirely agree that they should do it either,
but for tradition's sake, let's just keep the current behaviour with
them.
(In an ideal world the cursor business would be managed by the window
managaer IMO, but I'm not ready to argue my case.)
As I said in 739e2608db6b312a8e78b830e820a7970b52782c, the abbreviations
and names of campaigns in English tend to be better known by the
community, so they are also useful to consider when searching through
the list.
The description's untranslated version is also included in this even
though descriptions are longer and a bit more expensive to sift through.
It may still come in handy in cases where proper names get inflected or
transliterated I guess.
I thought this had been done in 217992a843f1ca9fc62eda02d0e376619ab786f7 but it turns out that was in the rejected version of the commit and didn't find its way into the final version.
Instead of reverting the schema and changelog mentions of it, I've just added the feature.
This gives GUI2 textboxes (and password boxes since they are a subclass)
a simple hover effect by extending the canvas definitions for the widget
accordingly.
This extends to a few other button labels used for replay control. While
checking if commit 46dbbc06c967bfc8ee5acb6525e1f1bd96b53005 was fit for
backporting to 1.14 I found out that "Play" was already in use
exclusively for one of the replay control buttons (which means, no, it
can't be backported). This makes the disambiguation markers absolutely
necessary.
To give a more practical example of why this is a big deal, in Spanish,
"Play" would be translated as "Jugar" in the context of the Campaigns
menu, and "Reproducir" in the context of a replay (or movie). The
Spanish translation in fact already uses the latter in both 1.14 and
master.
[ci skip]
I can see this dialog running out of vertical space on my Wine
configuration and winding up a victim of the dreaded Dialog-Wide
Scrollbar Syndrome.
[ci skip]
* revisions to mushroom terrain graphics to fix#4453
* make ^Tf overlay better mesh with water
* some touch-ups and more variety
* add some texture to base mushrooms
* new stone wall terrain variation -> catacombs
* Xot catacombs wall touchup and Efs flames overlay variation (candle)
* minor variations of walls can be spaced every other SE/SW facing panel
* make flames/torches overlay more responsive to type of wall variants if they are mixed
* Xot^Edb can now put skeletons in the SE/SW catacomb holes