This fixes the problem described in #13996 in a proper way.
This also adds "deadzone" property to ScrollContainer. It can be used
on mobile, where taps are not as precise as mouse clicks. Player could
slightly move their finger when tapping, in which case we still want
the button to be pressed rather than the container to be scrolled.
It seems that popups were intended to "grab" the mouse click that triggered them, but their intent was being lost. This commit does the necessary changes to let it happen and updates items that were trying to get advantage of it, because the semantics of `Control::grab_click_focus()` have changed a bit. Namely, it must be called **before** showing the modal.
This allows to popup a menu and activate an item in it in a single click-point-release cycle, instead of having to click once to open the menu and once more to pick an item.
This ability is extended even to context menus activated with the RMB (or any other mouse button, for that matter). The editor benefits from this in the context menu of the tree dock, which has been patched to opt-in for this feature.
This improves UX a bit by saving unnecessary clicks.
From now on, `PopupMenu` always grabs the click and also invalidates the first button release unless the mouse has moved (that's what `set_invalidate_click_until_motion()` was doing and now it's removed), so there is no longer the need of doing both things at every point a pop-up menu is shown.
They work exactly the same as current checkbox-decorated items, but in order to preserve compatibility, separate methods are used, like `add_radio_check_item()`. The other option would have been to add a new parameter at the end of `add_check_item()` and the like, but that would have forced callers to provide the defaults manually.
`is_item_checkable()`, `is_item_checked()` and `set_item_checked()` are used regardless the item is set to look as check box or radio button.
Keeping check in the name adds an additional clue about these facts.
Closes#13055.
When `RichTextLabel` calculated the actual width of columns, it let
them grow to sizes greater than its calculated `max_width`. Now this
PR ensures no columns grows beyond `max_width`, and the excess width
is distributed among the columns which can still grow.
It should fix#17731.
Text overflowed canvas as tables didn't calculate correctly the width
of their columns. They used the whole table width available for each
column. Also, the `cell` parameter was wrongly parsed if used with its
optional argument (expand ratio).
This PR fixs the parsing of `cell` parameter (i.e. `cell=e`) and the
distribution of the full table width between columns, but it overrides
automatically the `expand` flag if the column is smaller than it could
be, to allow a better UX out-of-the-box. It keeps the `expand_ratio`
flag to let the user customize how every column grows in relation to
the rest.
Partially fix#6289.
sersoong
Rémi Verschelde
ShyRed
Peter Folkins
Juan Linietsky
Poommetee Ketson
Paulb23
robfram
Pedro J. Estébanez
Ruslan Mustakov
ianb96
Gilles Roudiere
Wilson E. Alvarez
bosak
Fabio Alessandrelli
Hein-Pieter van Braam
Alexander Holland