Skip to content

Separate Menu.[open|close]Popup() methods instead of overriding hide/show logic - #701

Open
Gulvan0 wants to merge 7 commits into
haxeui:masterfrom
Gulvan0:master
Open

Separate Menu.[open|close]Popup() methods instead of overriding hide/show logic#701
Gulvan0 wants to merge 7 commits into
haxeui:masterfrom
Gulvan0:master

Conversation

@Gulvan0

@Gulvan0 Gulvan0 commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Gulvan0 added 7 commits July 19, 2026 19:37
…ing layout cursor

VerticalLayout.repositionChildren applied marginTop(child) only when
positioning the current child, then advanced ypos by componentHeight +
verticalSpacing alone. marginBottom never affected sibling spacing, and
marginTop of one child wasn't reflected in the next child's starting
position, causing potential overlap. HorizontalLayout had the same
issue with marginLeft/marginRight and xpos.

Fixes margin-bottom (and margin-right) silently having no effect on
sibling spacing inside vbox/hbox containers.
For each child, calcAutoSize computed the auto-size right/bottom bound as:

    x2 = child.left + child.componentWidth - marginLeft(child) + marginRight(child)

child.left already includes marginLeft (Layout.repositionChildren positions it
at paddingLeft + marginLeft(child)), so subtracting marginLeft again here
shrinks the computed auto-width by exactly that amount whenever a child's
margins are asymmetric. The left bound had the mirrored mistake, adding
marginRight instead of leaving it alone. Same pattern for y1/y2 with
marginTop/marginBottom.

Corrected: x2 should just extend past the child's box by its own
marginRight, x1 should retreat before it by marginLeft - no cross terms.
FocusManager.enabled ("whether or not to allow focus management
globally") was only consulted inside buildFocusableList(), which backs
pushView/onViewReady/focusNext/focusPrev and the focus *getter*. The
focus *setter* - the one that actually calls applyFocus()/unapplyFocus()
and, via StyleFocusApplicator, adds/removes the ":active" CSS class -
never checked it.

InteractiveComponent's mouse-down handlers (Button, CheckBox,
NumberStepper, Slider, OptionStepper, TextField, TextArea, ItemPicker,
TableView, ListView) set `this.focus = true` directly, which routes
through this setter. So with FocusManager.instance.enabled = false, a
mouse click still applied the ":active" style (e.g. a button's focus
outline) even though auto-focus and tab-navigation were correctly
suppressed.

Guard the setter the same way buildFocusableList() already is: when
disabled, do nothing.
Respect FocusManager.enabled in the focus setter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant