screen_pitch_microns is deprecated, and has been removed from the
GUI_SCALE_RESOLUTION macro in WML. The macro itself has been left in
place for potential future use.
The screen_pitch_microns variable has been left in place, but is now
a constant and will only ever return the default value equivalent to
96 DPI.
Fixes the text of menu_buttons being 1 pixel too high. Seems this is a relic from 2016 and me tweaking the
formula to try and get things more centered in buttons... But in that case, adjustments shuld probably be
directly made to buttons, not here.
These changes to the data/gui subdirectories make it so that above a certain
screen pixel dimensions (currently 1200x900), text font sizes will be scaled
with the pixel pitch of the SDL video device. In addition, several dialogues
(such as the unit recall window, for example) are allowed to take on larger
pixel dimensions to accommodate the larger (in pixel size) fonts.
[ci skip]
Since these are usually used inline or as key values, we don't need the extra padding.
(cherry-picked from commit 7db83e3a0e5de45b3e64eb1da784a8ce334a49c6)
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.
(cherry-picked from commit db5abb7e637fd87699fce49a9543faafc3f58068)
This reverts commit 9f386ed563e84e355130a940be804d13bf5b3d9c.
fixed_width/fixed_height are broken and completely fail to block the
widget from growing.
This makes it so the "selected" segment of the groove (towards the
slider origin) is drawn with a brighter color than the "empty" segment
(opposite from the origin). Since this obviously wouldn't work with
RGB #FFFFFF, and the color is too distracting anyway (it was pretty much
the only widget using the general *text* color), we now use the standard
UI border colors to match buttons, checkboxes and so on. This should
hopefully help with harmonizing Wesnoth's UI color scheme across the
board.
For this purpose we also introduce a macro for a darker/shaded disabled
text color, used for the unselected segment of disabled sliders.
