Re: The event API debate

On 01/01/2004, at 3:15 AM, Charles Goodwin wrote:
> On the face of things, one event API is preferable to two APIs.  But 
> I'm
> not sure it's that simple.

I'll think through all the conditions later, but I think what you said 
in the other message about states can be applied here.

The core Event traps are for physical state changes. Extra traps 
provided by the widget library are for meta state changes.

So:

hover -> Enter/Leave

This conversion isn't a problem, because under the old, true or false 
would be put to the hover trap. The person writing the hover trap would 
have to put an if() statement in there, with different code paths for 
true and false. Now, one path goes in the Enter trap, the other in the 
Leave trap. So multiple traps here don't cause a problem.

action -> Press1/KeyPressed

This situation requires two traps, but most widgets will respond 
differently to specialised keys. Eg.
   - the space bar may or may not cause a widgets action.
   - radio buttons in a group must have their action called by the
     arrow keys

It's up to a widget (Eg. in the case of radio buttons, I assume this is 
selectable or groupable) to check for certain keys, and make the 
decision on calling its action. Abstracting this away across multiple 
widgets that need to act differently is superfluous; it doesn't save 
any code.

I think extra standard traps should only be created where they are 
needed. Eg. focused or enabled. There's no way the Event model can 
represent these; they're meta states.

d