Tabbable/Pageable support in Framework

[focustense]

Library-based UI has access to the ITabbable and IPageable interfaces, the idea being that a WrapperView (now ComponentView) can implement these interfaces to hook the shoulder and trigger buttons for these functions.

This isn't available in StarML and it seems I just plumb forgot about it.

These interfaces are simple enough to carry over Pintail, but unfortunately I don't think it will work that way because they're not actually involved in the API call; if a client defines its own ITabbable and applies it to some view model, it's not going to be recognized as "the" ITabbable except with some duck typing (#21) and/or name-matching and signature comparisons.

Some other options I'm thinking of, with varying degrees of ugliness:

• A structural attribute like *tabbable that allows new event handlers next-tab=|...| and previous-tab=|...| to be defined. I'm not sure if this could actually be implemented in any way similar to normal events or whether or would just be a pile of hacks that pretends to act like a normal event.
• A pair of structural attributes like *next-tab={NextTab} etc., which is even more iffy in terms of implementation, though I guess if NextTab were an Action property as opposed to an actual method then it would be OK.
• An index attribute *tab={TabIndex} or *page={PageIndex} where the node increments/decrements the value; this is the most convenient for the framework but the view model has to do all the validation and possibly conversion from int to some other thing.
• Custom node types similar to <include>, e.g. <tabbable> or <pageable> with their own virtual events.
• Real, actual Tabbable or Pageable views that have real events and real tags, and act somewhat like frames (though this means they also need to have layout, context, etc.)

I'm not wild about any of these, but there's probably some iteration or mutation of one of them that will turn out to be relatively clean.

[focustense]

The more I think about this, the more I wonder if it's useful at all, vs. just defining a common button press event and letting models handle the appropriate buttons.

Tabbable and pageable really aren't strictly defined and vanilla menus like the Carpenter build menu use shoulder buttons for "pages" rather than "tabs". And controls really need to be able to handle button events anyway. The only downside is that it's easier to forget to add those button handlers vs. having something like a <tabbable>. Still, given the complexity and fiddliness of a one-size-fits-all solution, that might very well be a fair tradeoff.