> There is another question, related to key events. GGI key events contain a
> number of members, notably 'sym', 'label', and 'button'. In what way are
> these three members independent ?
Button is an arbitrary number, that is assigned to a physical key.
It is not portable between targets in any way.
Label is another way to specifiy the physical key pressed. It is more
portable, as it specifies the symbol that is printed on that key.
Sym is the symbol the key is intended to produce given the current modifier
state.
The three fields are used for different purposes.
> I understand that you may use a different 'mapping' (as in X), so a sym
> doesn't correspond necessarily always to the same key.
Most keys can produce multiple symbols, as they depend on the shifting
state. For example the key "Q" (label) on a german keyboard can produce
\x11 (ctrl), 'q', 'Q' (shift) and @ (altgr).
> However, given that the mapping is done at a lower level, isn't the goal
> to shield the application (GGI in this case) from the button ?
Yes, however it depends on what you want to do. there are three cases:
1. Inputting text. For this you will want to use the symbols. It saves
you lots of thinking about what you should do, if shift is depressed and
someone presses "a".
2. Controlling games. You would be pretty confused if you want to strafe
using "," and "." and say run with shift and then you can't straferun,
because you get "<" and ">" on an US keybaord, when shift is down, and
worse you get ";" and ":" on a german one. You should then use the label.
The label doesn't care about shift state - it cares about physical keys.
It has the advantage over the button, that if the manual says you got to
press "z" to lower the flaps, it will be "z" - and not "y" as it happens
with many US programs on german keyboards. Confuses the hell out of
some people ... we have to press "z" here at the BIOS question "Save and
exit setup ? <Y/N> _" ...
3. Controlling games, when keys will be teached in anyway. You can then as
well use the button, which usually gives smaller tables and better
searchability. However this is actually discouraged, as it is not portable,
even between targets.
> Shouldn't it then only care about the *meaning*, instead of
> the physical key being pressed ?
Depends - see above. Some applications want to know the meaning, others if
a key is up or down.
> And what about the label ? Is that pure convenience ?
It's kind of a "portable keycode".
> I'm asking as I didn't make up my mind about how to represent key events
> in berlin. We currently have a 'Toggle', which contains the (unicode)
> value of the key being pressed. Another member of the event, a 'telltale'
> may contain flags representing 'modifiers'.,
You will probably want something along the lines of the "label" field as
well. Games will need it. It would be a chore to have to hack in all
possible combinations with modifiers just to be able to check, if a key
is up or down.
> (the idea of berlin events is to totally abstract from physical devices,
> such as keyboard, mouse, etc.
Yes. That is the point behind the GGI event structure as well. You might
want to drop explicit mouse events and adopt the valuator scheme.
It should be capable of carrying anything that can be measured.
Maybe you also want to look into LibGIC. It is intended for games, but
there might be other uses. It is a configureable input mapping system.
> In order to be flexible towards new devices as well as 'device emulation',
> I prefer to synthesize events out of basic building blocks (toggles,
> telltales, positions, values, etc.) and then specify in a config tool what
> they mean and how physical (ggi) events map to them...
In that case you will probably want to look at LibGIC.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
