Previously, I had implemented the hint text ("Search)" and image (the magnifying glass)
as a custom text box definition. This caused some problems, though. Since the string was
hard-coded as part of a WFL formula, it couldn't be translated (see #2709 and #2732). It
also wasn't expandable to any other usecase.
Instead, I've added two new hint_text= and hint_image= keys to [text_box], wrapped the
"Search" text and magnifying image path in a helper macro, and refactored the default
definition to display the hint text and image when appropriate.
This also fixes a minor issue where selected text wouldn't remain highlighted when the
box wasn't focused when using the filter definition (it did with the default one).
This should fix the untranslatable "Search" text issue mentioned in both issues above.
The new string is in the wesnoth-lib textdomain.
Originally was going to do this as workaround for the background tiling over the borders,
but I fixed the root cause of that instead. Still, this just makes more sense.
This entirely refactors surface blitting out of the canvas. Instead, each canvas owns a texture. This texture
is completely redrawn any time the canvas if marked dirty, else the result is cached and drawn to the screen
each draw cycle.
All windows are now redrawn every draw cycle. The use of the cached canvas textures means there's no noticeable
performance difference (likely a performance gain, actually) from using surface blitting.
There's still some code to clean up and a few things to fix.
* Flipped the arrow on the Update icon set to point downwards, since it's a download operation.
* Renamed existing small Update icon set Publish, and added downwards version to replace Update.
* Renamed all addon manager icons and their respective button definitions to be clearer.
* Moved unused small icon versions to their own subfolder.
* Added separate Publish inline button to image list. This is now used in all cases to publish,
regardless of whether the addon has been uploaded previously or not. Prior to this, the Install
button was used for non-published addons, and the Update one for published ones. This means the
* Refactor addon_list inline button setup to be clearer.
* Made inline Uninstall button display in all cases where an addon was installed, instead of just
INSTALLED and NSTALLED_UPGRADABLE. It will not display if a publishable addon has not been
published, however.
* Changed is_local check to match the ADDON_INSTALLED_LOCAL_ONLY. I figured this is a bit more
robust. TODO: do the same in the addon manager itself?
Art assets credit to @Lordbob
[ci skip]
This prevents private chat logs being saved in your preferences file. History isn't
currently working anyway, and it seems weird to be saving logs this way, especially
since it also records private messages.
The old GUI1 addon manager displayed both local and published versions of the addon directly in the list
if the addon was upgradable or outdated on the server. It seems to have gotten lost in the transition, so
this restores it.
just liek the other fixes of this type this only 'reverts' multimenu buttons to the prviusly behaviour which is that the smallest resolution is only chosen for 600x800 resolutions, for other bigger resolutions like 601x801 the medium resolution is chosen.
Not sure why, but in some cases the overlay calculations were getting screwed up. This makes them use
the general centered image macro, with accompanying fallback safety checks.
We don't want markup in any of the other fields. I still need to find a slightly better solution for the name
field, though. We don't want users to be able to use markup unnecessairly, but we do need markup to highlight
the names of ready-to-upload addons.
This fixes warnings about unescaped ampersands in the Author field.
that commit onyl changed the resolution choosing procedure for windows
not for widgets which made that code more complicated. This commit also
addsa workaround for < 800x600 widgets to the c++ code so that we no
longer have to think about this in the .cfg files
The menu_button is now only a drop-down menu that supports a single selection.
A new multimenu_button widget supports a drop-down menu with multiple selections.
The new multimenu_button widget displays its current selection while not open.
