From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Mon, 21 Sep 1998 22:53:07 +1000

Other event tweakings

Hi again,

There are a few other improvements / clarifications / simplifications
I'd like to see happen with the current event structures in
include/ggi/events.h :

a) MODIFIER_DATA in the mouse events (pmove & pbutton).  This is so
wrong, mixing data from two input devices in one event.  Imagine having
multible keyboards and multible mice (like GGI Console allows), any way
of assigning which keyboard modifiers go into which mouse events is
surely arbitrary and thus meaningless.

I'd like to remove it.  Agreed ?

b) The `button' field of ggi_pbutton_event.  IMO it should be 0,1,2,3,..
and not 1,2,4,8,16,.. 

Why ?  It's so much easier to work with (on both sides, event generation
and event usage).  The only advantage in the latter would be sending
multible simultaneous presses or simultaneous releases... a pretty rare
occurance...

And it limits the number of buttons to 32.  For mice this doesn't matter
of course, but for other devices it does matter (the keyboard obviously,
and I've seen a joystick with 17 buttons ;-), and being consistent
across all devices would be a Good Thing (tm).

c) The `state' field of ggi_pbutton_event.  If it's really the
`previous state' like it says in events.h, then that is surely implied
by evPtrButtonPress/Release (and hence redundant).  If it's a bitmask
of all buttons in effect, then IMHO it is also redundant, since only 4
extra lines in a program are needed to recreate it:

    if (ev.any.type == evPtrButtonPress)
        mystate |= (1 << ev.pbutton.button);
    else if (ev.any.type == evPtrButtonRelease)
        mystate &= ~(1 << ev.pbutton.button);

Therefore I'd like to remove that too.  Agreed ?

d) The `normal', `sticky', and `locked' fields of MODIFIER_DATA.  These
fields are only there to show *HOW* the modifiers in `effect' came to be
in effect.  What is important is *WHAT* modifiers are currently in
effect (the `effect' field), but who cares *HOW* ?  This is useless
information that no applications will need to know.

Applications are still free to do funky things with modifers, by
tracking the `sym' or `label' fields of key events.  They are not
disadvantaged or hindered in any way if those three fields disappear.

Thus I'd like to remove them.  Agreed ?

e) Ok, last and definitely least ;).  Those ev*State events.  Nothing
implements these, and IMHO nothing will ever need to.  The idea of a
`device state' really goes against the grain of an event based approach. 

It's a matter of how this would ever be implemented.  To get the 
`device state', LibGGI would need to ask the next-higher-up thing (e.g.
GGI Console) for the state.  GGI Console would then need to ask the
next-higher-up thing (the input-stack ?) for the device state, and so on
... until we reach the device itself.  All this implies the need for a
another API (separate from the event API) for querying `device state',

If we had such an API for querying device state, then why use events in
the first place ?  Do you see what I'm getting at ?

I don't see the need for it anyway.  You start a program with a shift
key held down, or a mouse-button depressed, and the program doesn't
notice this -- so what ?

So how about removing those ev*State events ?

Cheers,
______________________________________________________  ____
                                                        \  /
  Andrew "Axeman" Apted   <andrew@ggi-project.org>       \/