Re: The event API debate

Charles Goodwin wrote:

>Just to further elaborate (as opposed to reply to my own mail)...
>
>The widget API implements an 'action' for clickable widgets.  The basic
>example is a button.  So, if you want do something when a button is
>used, it simple:
>
>action += function( v ) { ... }
>
>Now, using _1_ API, I'm not entirely sure how this is going to work. 
>Are we going to use Press1?  Or Click1?  Or Release1?  And what about
>when a button is activated using a keystroke (ie 'enter' or 'space')?
>
>So to replace the above, we'll be mandating:
>
>myaction = function( v ) { ... }
>
>Release1 += myaction;
>KeyRelease += myaction;
>
>This is why we shouldn't be writing off a widget API.  A widget API
>simplifies things, it presents only what is needed to be known of the
>widgets.  We may find that trying to contort a widget API through the
>core API is not going to result in an intuitive interface for users.
>
>KISS.  What is simpler?  2 APIs, where 1 is only used for areas the
>other doesn't cover?  Or 1 API that requires a bit more (for want of a
>better term) know-how in order to use?
>
>- Charlie
>
>  
>
It seems obvious that any widget should be able to expose it's own 
mini-api. Suppose, for example, that you have "SpinnyWidget" which has 
two modes - spinning and not spinning. The widget has very complex 
dependencies determing whether it spins or not (obAbsurdism: it spins 
for 3 seconds every time a menu is selected and the time is between 4:30 
and 4:35). It should be possible to trigger events everytime that widget 
stops or starts spinning without having to worry about the 
implementation details. I don't see how the one API approach would 
address this at all. You would have to re-implement the "is it 
spinning?" logic every time you wanted to use the widget.

Conceptually, maybe we shouldn't look at it as two separate APIs, but as 
extending the core API.

-Tupshin