Discussion: pluggable ScrollBar renderer

[nitzan-shaked]

(for poc impl see #1496 )

In #1461 I proposed a "thin" horiz scrollbar and @willmcgugan made several points around the modeling (was it another property? what did it override? the typing itself of the css I proposed; and similar). Will suggested a pluggable "scrollbar renderer", which would decouple the code I wanted to merge from the rest of the codebase, also allowing for an eventuality where this code is massaged and eventually does make it in but not until all are happy with it.

I like the idea and am happy with the direction, and would like to discuss what such "pluggable renderer" might look like.

I'll start by saying the discussion could be endless. Is this a framework for scrollbar renderers? For ANY renderable? For any PLUGIN? And, in each of those options, what is the "discovery" mechanism? What is the exact interface and the modeling of roles & responsibilities?

My thinking is that these are things learned slowly, so best is not to over-design/over-commit, still making sure no too-specific code makes it into "main". Given that, I propose the following:

• An interface for a "ScrollBarRenderer", accepting only exactly the parameters "ScrollBarRender" accepts today, and forced to adhere to them (so the semantics of everything existing is kept exactly as is).
• A simple, Pythonic auto-discovery mechanism for classes implementing this interface. (See class_registry.py and scrollbar_renderer_registry in scrollbar_render.py)
• A class implementing the interface which would be the default renderer, and does exactly what is done today for rendering a scrollbar.
• A styles property called scrollbar-renderer, which must be one of the available renderer classes.
• The idea is that other renderers would be configured out-of-band, so CSS is not involved at all other than specifying the name of the class. Nothing more.

To show how this actually works, I've also included:

• A sample "thin scrollbar renderer", which in my PR sits in scrollbar_renderer.py but in the future will sit in user/dev code, outside of this repo. It shows how I think about this.
• A change to demo.css to make use of it (one line, in the DataTable selector).

The PR is (imho) a nice starting point, but I'm not married to anything in particular there; rather, it is intended to explain what I think in better terms than my prose above. It does work for me, and passes tests.

I'm very happy to hear thoughts.

[nitzan-shaked]

(EDITED: I changed this into something even simpler)

Updating: in #1496 @willmcgugan writes:

This would essentially modify the CSS grammar at runtime, which would be a deal breaker. CSS would no longer be portable, and it would depend on the order you import things.

Modifying scrollbar visuals is not something we want to support now. We have bigger fish to fry. I wouldn't accept any significant changes, but I would consider a hook you can use to plug in a different scrollbar in your code base. A classvar on the Widget feels the simplest.

Okay I'll go with that. I appreciate you have bigger fish to fry, and indeed am striving to make this the least intrusive possible.

My thinking then is the simplest I can come up with:

Class Widget will have a classvar scrollbar_renderer, whose type is type[ScrollBarRender]. That is: it holds a reference to a class that is or is derived from ScrollBarRender. It will use that instead of directly saying ScrollBarRender. That variable will be mutable, and for starters I am not even planning any watchers on it etc. The perceived use-case is for the dev to derive from ScrollBarRender, import Widget, set the class variable to the new class, and continue on their merry way.

Is that reasonable?

[nitzan-shaked]

Updated #1496. It is now a 3 line change in one file, and I hope that's what you meant.

I also included a demo_thin_scrollbar.py which is not meant to be part of the repo, just to show how this would be used, and the fact that it does what's required.