Since an idea is finally forming in my head, I'll start explaining it and see where this leads.
In order to have a widget that scrolls, we basically need a view that is restricted to a certain size, but which contains more child elements than would fit onto the screen. The view would then have an offset that would basically tell which part of its contents should be visible. From the size of the content and its own, it can calculate the amount that's actually visible and present a scrollbar to the user that would reflect that. Starting with that simple premise, I'd model it like a viewport in Java. In terms of our GUI class hierarchy, it would be a layout that can have exactly one child (another layout). Being a layout itself, it can act as a toplevel window, reducing the amount of nesting that would become necessary otherwise. Its draw method will add the offset and use an appropriate clipping rect to show the part of the child that should actually be visible, so scrolling will be transparent to the layout being scrolled. And of course It also renders the scrollbar(s), which for now will only be an indicator. In the future, once we enable mouse support throughout the GUI, they'll have to become active elements too. Sounds simple, clean and easy to use, right? :-) Anything I may have missed? Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
