Scroll refinements about druid HOT 2 OPEN

Miscellaneous thoughts, based on many years of exposure to scroll bars, scrolls of antiquity, cheese and vegemite scrolls, certain projects with unusual scrolling behaviour, and the Fastmail web app where we have to be too clever for my liking about some of these things, but in a very successful way (because we work with what we’ve got rather than trying to reinvent the world):

Not all scrollable containers want scrollbars; maps, for example, want to be scrollable, but not show scrollbars. Infinite-scrolly things may or may not want scrollbars. I don’t know whether this should be something like an enum { NotScrollable, HiddenScrollbar, VisibleScrollbar } per axis, or whether scrollbars should be a separate widget.

Native scrollbar appearance and behaviour is very strongly desirable, but may not be readily replicable. At the same time, you probably want it to be stylable with at least something like CSS scrollbar-color and scrollbar-width. The ideal colours can vary based on the content being scrolled, even if it’s as simple as light versus dark.

Native scrollbar positioning may entail overlay scrollbars (e.g. macOS by default, Windows 10 UWP apps by default), or may take space out of the layout (e.g. Windows 10 Win32 apps).

Native scrollbar behaviour may require drawing outside the window client area, e.g. Unity’s overlay scrollbars from 2011 (I have no idea if that’s changed since then, I haven’t used Ubuntu for years; now that Ubuntu has switched to GNOME 3 I have no idea of the situation either).

Nesting of scrollable areas is very fiddly and varies by platform; see also the CSS overscroll-behavior property.

It can sometimes be desirable to have the scroll behaviour operating outside the rectangle that scrollbars would seem to operate upon; for example a spreadsheet may draw the scrollbars on the cells, but expect scrolling on the window chrome to scroll the sheet.

Focus is a fascinatingly complex area, particularly as regards using the keyboard for scrolling. In general, you want a scrollable area to be sorta-focusable: for example, that clicking inside it activates it, for scrolling purposes, but that if a widget inside it is focused then clicking on the scrollbar shouldn’t focus it. Other times you want keyboard scrolling to affect a particular pane, e.g. in a three-pane email client (mailboxes, messages, active) you want the email pane to be the default (and perhaps only) focused one for keyboard scrolling purposes.

from druid.

Continuing my thoughts from #799 (see this comment)

My idea is to distil some common scrolling logic into a scrolling component which widgets can use to easily achieve customized yet consistent scrolling behaviour. I want to avoid trying to shoehorn some method of a widget detecting if it is in a Scroll and using commands or something similar to coordinate between the two, which would be even more cumbersome for downstream widgets for which attempting to make a required modification to Scroll to enable some different behaviour is a much more difficult option.

The usage case for customized scrolling are text edit widgets which need to be able to set their own scroll offset when the caret moves out of paint bounds, widgets which need to be able to grab the paintable size of the window where their contents will be painted with offset, and allowing builtin vertical and horizontal scroll list widgets to be independent widgets.

The current Scroll code isn't very long which is good but it is still the product of a fair bit of work as well as trial and error which it would be nice to not require downstream widgets go through or even flat out copy paste. Stuff like detecting scrollbar mouseover, dragging scrollbars, painting scrollbars, a helper function over paint_with_save for widget contents, calculating free space after inset scrollbars have consumed paintable area, ect are all things I want to expose as individual methods which a widget can then plumb into in only a handful of line allowing the widget to instead worry about layout and its own contents while having more control over its scrolling state while the component does the paperwork to track offset, drag state, ect.

I wanted to get any input on this before starting work on a PR as I'd like to avoid working on an approach which does not have support.

from druid.