Interactive but non-Input Widgets

[patrickbkr]

The RichText widget and also the upcoming TreeView widget are both interactive. One can scroll the view, there is the concept of selectable rows and the TreeView entries can be opened / closed. By default they are not necessarily Inputs in the common sense.
The LogViewer is another such case. I'd say it makes sense for it to have focus to allow it to be scrolled.

Maybe interesting: It's not yet implemented, but I'll give the RichText widget an optional cursor. Building a RichText widget subclass that allows editing the content is then trivial. Such a sub class would then be a legitimate Input widget.

Not inheriting from Input has these consequences:

• Don't take part in tab order.
• Have no concept of being focused.

Inheriting from Input pulls in quite some functionality I'm not necessarily interested in:

• hints
• &process-input
• error

Is this enough reason to introduce an intermediate role called Interactive or something like that?

[japhb]

Ooh yeah, this is a great idea. I hadn't decided what I was going to do with the mismatch you're talking about, but Interactive seems like a good middle ground for now.

Feel free to give it a go if you like, or I will next time I get some hacking tuits.

[patrickbkr]

I can give it a try. What do you think about Focusable as the role name?