EdJoPaTo

> I wonder whether it's worth considering a more explicit builder approach for the incremental build needs? Effectively meaning `T::default().x()` becomes `T::builder().x().build()` in user code. For most widgets I don't...

Just stumbled upon this as I wanted to have scrollable Table widget. It enforces the selection to be always visible which is slightly annoying but ok. What is really annoying:...

Implementing generic scrollbar support for my Tree widget was also straightforward (see [commit](https://github.com/EdJoPaTo/tui-rs-tree-widget/commit/92466615b1bd20d9ce8fc0af0e4e32779d9f8a02)). Needing the margin extra seems a bit annoying. As the scrollbar is already handling positioning (left right...

I improved mouse scrolling with intensive widgets by debouncing the mouse events. It looks best when one event equals one line. In my case the events are cached for 20...

I think I have a good approach for the Scrollbar configuration: Just like the user configures a Border for a given widget the user should be able to supply a...

Another question that comes up: scroll the offset or the selection? With mqttui (and therefore my Tree and Binary Data Widget) I went for scrolling the offset which is something...

Scrollable widgets should include a common `ScrollBehavior` struct. This should be the same for all widgets in an application in order to create consistent behavior across widgets. This should be...

> I don't mind keeping these available to people (as building blocks for other widgets) My idea was not to completely remove these building parts. But they should not be...

Enabling the lint and fixing the places yeah. But also finding cases where this lint is not noticing this bad behavior to report this and improve the lint (for us...

#965 is an attempt of me to configure something like this but no one seemed to be interested enough to look into it so far (so I haven’t continued working...