Alex Perry writes:
> I like the concept of the mice.xml file, but am not really
> comfortable about having the implied modal state hidden in there.
> Can we break it out, so that mouse, joystick and keyboard events
> can be conditional on state variables ?
Thanks for looking at the code.
There are a few things I'm trying to decide right now. First, I'd
like to get all state variables out of the /input tree -- the current
mouse mode, x- and y-position, and (soon) button status should all go
in some other subtree, such as /devices/mice (we desperately need to
do that high-level reorg of the property tree).
As for the mouse mode, it is accessible from any bindings using
conditions, such as
<key n="??">
<binding>
<condition>
<equals>
<property>/input/mice/mouse[0]/mode</property>
<value>1</value>
</equals>
</condition>
<command>property-assign</command>
...
</binding>
</key>
In fact, I had originally implemented mice.xml that way (as you
suggested in your example), but it seemed very verbose -- I have no
objection to putting it back if it doesn't scare away everyone else.
Yet another option is to allow a fixed maximum number of modes (say,
10) and make them into pseudo-modifiers; we could do the same for
mouse buttons. That's not really necessary any more with conditions,
though.
> The other benefit is that the keyboard can easily become modal. We
> don't currently support key sequences and stateful decoding of
> keyboard input, which severely limits our ability to tie useful
> controls to keys.
Modal key input is fully possible currently with clever use of
conditions, but it is very verbose. Let's say that we wanted 'X' to
start an input sequence:
<key n="88">
<binding>
<command>property-assign</command>
<property>/status/modes/x-mode</property>
<value>true</value>
</binding>
</key>
and then 'a' to be the second key of such a sequence:
<key n="97">
<binding>
<condition>
<property>/status/modes/x-mode</property>
</condition>
...
</binding>
<binding>
<condition>
<property>/status/modes/x-mode</property>
</condition>
<command>property-assign</command>
<property>/status/modes/x-mode</property>
<value>false</value>
</binding>
</key>
I agree that that's hideously ugly. It's a little cleaner if you just
want X to be a modifier key, since it can clear its own flag on release:
<key n="88">
<binding>
<command>property-assign</command>
<property>/status/modes/x-mode</property>
<value>true</value>
</binding>
<mod-up>
<binding>
<command>property-assign</command>
<property>/status/modes/x-mode</property>
<value>false</value>
</binding>
</mod-up>
</key>
Exactly the same trick works for any joystick or mouse button.
> The final benefit is that it explicitly allows chorded buttons on
> the joystick to be decoded. This is useful for people with low
> button count joysticks. I also see a benefit in having a clean way
> (compared to how we do it now) of switching a joystick axis between
> multiple analog input options.
This can be handled the same way, though again, it will be verbose.
I'm trying to figure out some structural simplifications. One problem
with using conditions is that you have to use them anywhere -- if I
set up modal input using conditions, bindings that don't know about
the mode will charge on blindly ahead; modifiers, on the other hand,
cause bindings that don't know about them to be skipped.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
