Programatic scrolling should work without scrollbars (overflow hidden).

[willmcgugan]

Currently if there are no scrollbars, and you call Widget.scroll_to, the scrolling us suppressed. This is so that moving the scroll wheel doesn't scroll when the CSS has disabled scrolling.

However, some times you may to scroll a container programatically. Suggest we need to differentiate scrolling initiated from mouse / keyboard input and programatic scrolling.

[davep]

Quick test code to visually confirm the issue (using scroll_to_widget, which I imagine is part of this issue too?):

from textual.app        import App, ComposeResult
from textual.containers import Vertical
from textual.widgets    import Header, Footer, Button
from textual.binding    import Binding

class ScrollToTester( App[ None ] ):

    CSS = """
    Vertical {
        overflow-y: hidden;
    }

    Button {
        margin: 1;
        width: 100%;
    }
    """

    BINDINGS = [
        Binding( "j", "jump", "Jump to a button off the screen" ),
    ]

    def compose( self ) -> ComposeResult:
        yield Header()
        yield Vertical(
            *[ Button( str( n ), id=f"btn-{n}" ) for n in range( 200 ) ]
        )
        yield Footer()

    def action_jump( self ) -> None:
        btn = self.query_one( "#btn-150", Button )
        self.query_one( Vertical ).scroll_to_widget( btn )
        btn.focus()

if __name__ == "__main__":
    ScrollToTester().run()

Pressing j should bring button 150 into view.

[davep]

Note to self: diving into the code, in the above situation, scroll_to gets called and returns True; so as far as it's concerned it did scroll. Whatever needs changing, it looks like it's down in the animation code, most likely.

[davep]

Tracing further, a quick fix to this is this:

diff --git a/src/textual/widget.py b/src/textual/widget.py
index 7808f1a0..67c140b7 100644
--- a/src/textual/widget.py
+++ b/src/textual/widget.py
@@ -811,8 +811,8 @@ class Widget(DOMNode):
     def watch_scroll_y(self, old_value: float, new_value: float) -> None:
         if self.show_vertical_scrollbar:
             self.vertical_scrollbar.position = round(new_value)
-            if round(old_value) != round(new_value):
-                self._refresh_scroll()
+        if round(old_value) != round(new_value):
+            self._refresh_scroll()

     def validate_scroll_x(self, value: float) -> float:
         return clamp(value, 0, self.max_scroll_x)

I'm not sure at the moment if this is the way to do it, but this has the effect I'm after here and would seem to narrow it down to watch_scroll_y (likely also need to consider the same for watch_scroll_x too).

[davep]

Testing/checking more, this does seem to have exactly the effect we want, but confirming it with @willmcgugan he's said it would possibly be beneficial to have a method of optionally blocking by-code scroll as well (the above change would still block input-based scrolling, but always allow by-code scrolling).

Need to find a bit of time to dive into this further to understand the use-case for that.

Meanwhile I'll draft a PR with the above changes as a placeholder for what we want.

[davep]

Following on a little more, it's been noted that Widget has allow_horizontal_scroll and allow_vertical_scroll properties, which watch_scroll_x and watch_scroll_y are bypassing. It would seem that they should make use of them.

[davep]

Further to the above: in further discussion, it's been suggested that all of the scroll_-prefixed method that have the side-effect of making a scroll happen should have a force keyword parameter, which will be used to override the relevant allow_ property. Following this through, to help try and grok this, let's look at what would happen if scroll_visible where called.

• scroll_visible gets called on a given widget.
• scroll_visible books a later call to scroll_to_widget, scrolling to the parent of the given widget.
• scroll_to_widget walks the parent chain of the given widget, using scroll_to_region to ask each container in turn to scroll to make the widget visible.
• scroll_to_region starts to work out what horizontal and vertical scrolling is required, and then calls scroll_relative to make the scroll happen.
• scroll_relative is a fairly thin wrapper around scroll_to.
• scroll_to is where the scrolling is actually kicked off.

I still need to check other paths but I imagine that all roads lead to scroll_to. The next thing to figure out is how we can know what direction we're scrolling in at this point. Both x and y can be None to indicate "no change" but at this point I'm not confidant that that's all there is to this.

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.