Re: widgets plan proposal

> So how in your model is it made the exception? What code do you use?
> 
> It's an exception that pops up a lot. Toolbars generally are clickable 
> but not focusable, along with the buttons in a scrollbar, the scrollbar 
> entity itself (which needs all the functionality of clickable without 
> holding focus), and a good range of custom items: iTunes control, 
> Safari back/forward, display selector in iCal, etc.
> 
> On a slightly different note, do you consider the headers of a table 
> clickable?

Firstly, they are very good examples of clickable but non-focusable widgets.

We have modified focusable to incorporate the ability to do this easily.

And I find my thoughts conflicting here.  But not about our implementation,
but about monopoly... we're going for an identical copy... yet I can think
of no reason why the toolbar is not focusable... it should be.  And I can
think of no reason why the table header is not focusable... again it should
be.

So I propose that, here, we deviate from monopoly in a very small way, and
make toolbars / table headers focusable.  But focusable like radiobuttons...
when you tab you don't tab between radiobuttons, but between radiobutton
groups.  And you should be able to tab between toolbar / table headers and
other focusables and navigate toolbar / table headers with the arrow keys.

Back to how the model works.

The model we've made works towards xwt utopia; pure ease of use of the
widget set.  And relatively simple theme creation.

For example, take scrollbar.  It has 3 buttons in it; the next and previous
arrows (aka up/left and down/right), and the thumb.  Now, rather than
complicate the theme implementation (have to create separate buttons that
don't preapply focusable).  Focusable has the property 'subfocusable'.  When
subfocusable = true, it says 'I don't want to ever get tabbed / focused'.
Yes, it somewhat defeats the point of focusable, but it really simplifies
making a scrollbar.  Then xwt.standard.widgets.scrollbar puts
subfocusable=true to the 3 buttons when they are added by the theme.  It's
simple.

However, I want the above to be focusable, but to use selection_mux as well.

Thoughts?

Also, on another point, to simplify some root -> key issues with focusable -
adding keys to it outside of the focusable xwt, and having widgets that are
interested in used keys like tab - I'm thinking that focusable should have a
static list of keys that are being listened for.  When we get into doing
menu, with A-key access, this will be important.
_______________________________________________
http://lists.xwt.org/listinfo/dev