Re: The event API debate

On Wed, 2003-12-31 at 22:48, David Crawshaw wrote:
> 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.

Wrong.  (Excuse the bluntness!)

hover was a state-trigger trap.  Only 'true' was ever put to it.

Also, hover != Enter/Leave.  The condition 'hover' is a visual condition
that occurs when a button has the mouse over it but is not activated.

So, you have two conditions when 'mouseinside' is true; if 'activated'
is true then the clickable is 'active', else it is set to 'hover'.

> action -> Press1/KeyPressed

This is again false.  (Again, excuse the bluntness!)

If you play with the win32 widgets (the actual ones), you'll see that
most actions are triggered on Release, not on Press.  You can press a
button and hold it down without activating it by either pressing escape
or by moving the mouse away from the button and releasing.  Also, if you
press outside of a button, move the cursor over it, and release nothig
happens.

But, even so (all this could be 'masked'), you're mandating extra code
in order for it to work[1] which is not intuitive, as well as altering
the behaviour of the core API in a way that might confuse[2].

[1] see previous email
[2] "Why is this doing this and that doing that?"

> 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.

I agree, but having put a _lot_ of time into working out how widgets
function across various platforms, I can gold-plated guarrantee you that
the core API is not expressive enough to non-confusingly represent
clickable widgets.  It provides the means to do them, but the 'doing' is
different to the 'being'.

Clickable simplifies the whole thing quite nicely.  Have a look at the
xwt.lib.abstract.clickable code from the lithium widgets.  Whilst
sparsely commented, it is an elegant solution and one that greatly
simplifies theming clickable widgets as well as using them.

I honestly don't think you can produce an as-elegant solution that maps
onto the core API.  Of course, I'm not closed minded about the matter,
but your post did present some fundamental misunderstandings of how
clickable works, how widgets work, and what the theming requirements
are; probably because you've been out the game for a while.  (No offense
is intended!)

- Charlie

PS.  I will note that I've learnt - by being too vocal and probably
quite annoying - that "Adam and David are almost always right" so if I'm
disagreeing strongly then it's because I have _knowledge_ (yes!) to back
it up. :P

-- 
Charles Goodwin <[email protected]>
Member of the XWT Foundation

The future of the net - www.xwt.org