[BUG] Overflow.SCROLL may not be working properly

[leftbones]

The scrolling example has a box of colors, you can scroll up and down with the arrows or mouse wheel, but the view never moves, the cursor will move down off the screen.

I also tried adding ptg.Overflow.SCROLL to a container that held a label which was more lines than were visible on screen, and scrolling the mouse and arrow keys does nothing at all. I assume if I had a cursor visible, I would see the same thing where the cursor would go off the screen.

My code, just for completeness sake:

        contents = ptg.Container(
            ptg.Label(
                lines,
                parent_align=ptg.HorizontalAlignment.LEFT
            ),
            overflow = ptg.Overflow.SCROLL
        )

[bczsalba]

I am sad to admit, but at the moment that is all it's supposed to be doing. In the next minor update I am planning on introducing a ScrollView widget, that handles these things smartly, does focus-scrolling and has a scrollbar.

The big problem I have right now is that all widgets have to be _fully_rendered before being displayed, even if they are "scrolled". And even then, scrolling on "hides" widgets, not lines, so trying to "page" a highlighted file is ridiculously bad performance-wise. I am planning on introducing optional arguments to get_lines that will try to coerce it into only showing a specific range of lines, but I'm not sure of the APIs yet.

Actually, minor related question: Should the scrollbar be on top of the right-most character column, or should it make the content smaller and occupy a now empty area? I prefer the second one, but it means re-rendering at least once when the scrolling threshold was reached.

[jeffwright13]

Regarding your minor related question: if you're changing APIs, why not just make that a configurable option?

[bczsalba]

Mostly just extra complexity that might be problematic in the future. It could be configurable, but that means implementing both ways. We shall see how difficult that is, lol.

[leftbones]

Mostly just extra complexity that might be problematic in the future. It could be configurable, but that means implementing both ways. We shall see how difficult that is, lol.

Perhaps take a look at how Textual implements the scrollable views and scroll bars, I played around with Textual a little bit (it's too new to do much with at the moment, and the documentation is basically nonexistent) and didn't see any noticeable performance loss in a scrollable view with syntax highlighting.

[leftbones]

Just some thoughts:

This is still doable right now if you want to use a scroll offset that increases or decreases when it gets too close to the top or bottom of the window boundaries, then you just offset the contents you're printing by the scroll offset. I do the same thing in curses for both horizontal and vertical scrolling.

I haven't experimented with the mouse integration in PTG yet, but I would imagine you could probably map the scroll wheel to control this offset as well.