Includes:
* New ui::Style::rawMargin/Border/Padding() to detect what values are
undefined, and ui::Style::margin/border/padding() to return normalized
values (replacing kUndefinedSide with 0 when a value is not defined in
the whole hierarchy of styles). With this change we avoid using a
margin/border/padding value of -1 by mistake.
* New guiscaled_div() to calculate an integer division taking care the
guiscale() for a scaled value.
* CALC_FOR_CENTER() renamed to guiscaled_center() and moved to ui/scale.h
There are still a lot of work to be done to fully fix these UI issues
between Screen Scaling=200%/UI Scaling=100% vs Screen Scaling=100%/UI
Scaling=200%
Parts of this commit are from #4968 and will be useful to reuse in the
multiline TextEdit widget.
Co-authored-by: Christian Kaiser <info@ckaiser.com.ar>
We have to fill/use the X position of each char box instead of
calculating it through the width of each glyph (because each advance
is different from the glyph width in isolation).
Now we don't render the default ui::Entry edges, but we paint just a
border of the text bounds + the rendered text highlighting selected
text on the canvas itself.
With this change click mouse positions are translated with a scale
factor that changes depending on the app::Editor zoom.
As the new text::draw_text() can draw text with "native" (Skia) fonts,
we have to pass the font manager (text::FontMgr) to it, which is in
SkiaTheme. So we've added a new abstract fontMgr() member function to
ui::Theme to get the active font manager.
We've refactored the code to support locating windows (and popups
windows + hot regions) correctly in both modes: with one ui::Display
and with multiple ui::Displays.
For this we've added a new ui::fit_bounds() function that works in
both modes.
This ui::Display is related to one native os::Window, so the dirty
region/invalid region is now part of a ui::Display instead of a
ui::Manager.
* Replaced ui::display_w/h() functions with ui::Display::size()
and ui::get_desktop_size()
* The ui::Manager contains the main ui::Display, and in the future an
ui::Window will have its own ui::Display
This is the first version of the feature, it still needs some
fixes (e.g. avoid skew transform when the pivot is in the same side of
the skew handle which can calculate a division by zero).
This is related to #1100, as the Linux port is not well tested and may
fail, it's good to have an option to disable the native clipboard code
just in case.
If a text field (ui::Entry) contains text with length=1 (e.g. the number
"8"), and we focus and press that same char ("8"), the caret will be in
the position 0 with text "8" (the caret should be in position 1). this
patch fix this behavior.