You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#513 lands ScrollView with wheel routing, overlay bars and track paging. The design it came from split the remaining work into a second phase and a list of things to do only when wanted. This ticket records both, so the next phase starts from a written plan rather than the PR discussion.
Phase 2
Thumb dragging.IPointerTarget deliberately has no move notification, so a bar can only page today. Add IPointerDragTarget : IPointerTarget with OnPointerDrag(Vector2Int position, MouseButton button), called from PointerRouter.Moved for every captured element that implements it, with the same route-version checks the other callbacks have. ScrollBar records the grab position on a thumb press and maps each drag to an offset through the thumb's travel; a press on the track keeps paging.
Horizontal-only views take the vertical wheel. A plain mouse wheel produces only a vertical delta, so a ScrollView whose Axes is Horizontal cannot be wheeled at all (found while testing Add ScrollView to Pixely.Ui with wheel routing and overlay scrollbars #513). When the vertical axis is not in Axes, treat the vertical component as horizontal, with the same refuse-at-the-end rule so it still bubbles to an outer vertical list at the ends. A view with both axes keeps the components apart.
ScrollView.ScrollIntoView(Element descendant). Resolved at the end of ArrangeContent from the descendant's Bounds against the viewport, and kept as a pending request when layout is dirty at the time of the call. This is what a future Tab traversal needs to keep the focused field visible.
Later, if wanted
Shift+wheel as horizontal scrolling. MouseWheelEventArgs carries no modifiers, so this needs either the keyboard service in UiInputSystem or a modifier on the event.
Keyboard scrolling of a focused scroll view, once focus traversal exists.
A ScrollChanged notification. Deliberately left out: it would be raised from arrange, and a subscriber that invalidates during a build shows its change a frame late.
Exposing SDL's wheel direction flag on MouseWheelEventArgs for an application that wants raw device motion. The UI deliberately takes the platform's values, natural scrolling included, so this is not needed for scrolling.
Notes for whoever picks this up
docs/ui.md, section Scrolling, describes what phase 1 does and states the bars cannot be dragged yet; update it with each item.
Pixely.Tutorials.UiScrollView has a vertical list and a horizontal strip; item 2 is what makes the strip usable with an ordinary mouse.
Tests live in tests/Pixely.Ui.Tests/ScrollViewTests.cs and ScrollRoutingTests.cs; RecordingScrollTarget and RecordingPointerTarget are the fakes to extend.
#513 lands
ScrollViewwith wheel routing, overlay bars and track paging. The design it came from split the remaining work into a second phase and a list of things to do only when wanted. This ticket records both, so the next phase starts from a written plan rather than the PR discussion.Phase 2
IPointerTargetdeliberately has no move notification, so a bar can only page today. AddIPointerDragTarget : IPointerTargetwithOnPointerDrag(Vector2Int position, MouseButton button), called fromPointerRouter.Movedfor every captured element that implements it, with the same route-version checks the other callbacks have.ScrollBarrecords the grab position on a thumb press and maps each drag to an offset through the thumb's travel; a press on the track keeps paging.ScrollViewwhoseAxesisHorizontalcannot be wheeled at all (found while testing Add ScrollView to Pixely.Ui with wheel routing and overlay scrollbars #513). When the vertical axis is not inAxes, treat the vertical component as horizontal, with the same refuse-at-the-end rule so it still bubbles to an outer vertical list at the ends. A view with both axes keeps the components apart.ScrollView.ScrollIntoView(Element descendant). Resolved at the end ofArrangeContentfrom the descendant'sBoundsagainst the viewport, and kept as a pending request when layout is dirty at the time of the call. This is what a future Tab traversal needs to keep the focused field visible.Later, if wanted
MouseWheelEventArgscarries no modifiers, so this needs either the keyboard service inUiInputSystemor a modifier on the event.ScrollChangednotification. Deliberately left out: it would be raised from arrange, and a subscriber that invalidates during a build shows its change a frame late.directionflag onMouseWheelEventArgsfor an application that wants raw device motion. The UI deliberately takes the platform's values, natural scrolling included, so this is not needed for scrolling.Notes for whoever picks this up
docs/ui.md, section Scrolling, describes what phase 1 does and states the bars cannot be dragged yet; update it with each item.Pixely.Tutorials.UiScrollViewhas a vertical list and a horizontal strip; item 2 is what makes the strip usable with an ordinary mouse.tests/Pixely.Ui.Tests/ScrollViewTests.csandScrollRoutingTests.cs;RecordingScrollTargetandRecordingPointerTargetare the fakes to extend.