David Megginson writes: > >Norman Vine writes: > > All that is needed is a way of storing 'mouse state' per mode > >When you switch into a mode, you would need to initialize to the >current property value, not to the previous screen position -- the >property value very likely has changed since the last time you were in >the mode controlling it.
Yep :-) >I never realized that you were doing this in the old mouse code so I >didn't pay attention when I still had it configured in, Then I guess it was working 'perfectly' :-) >but it seems >more difficult than you're suggesting. For example, let's say that in >one mode left/right mouse motion is controlling the ailerons when no >mouse buttons are pressed, the rudder when the left button is pressed, >and the brakes when the right button is pressed -- we're going to have >to keep track of each one and warp it to the correct position on any >button presses. I guess so. But this is quite important, For example I have found in my limited experience with the new mouse code that since the cursor behaviour is VERY different from the older method and I find my self making inadvertently making DRASTIC trim and or view changes while cycling thru the Mouse modes. ie I normally keep my cursor hidden and with the old code the cursor would appear offset relative to the center of the screen depending on the 'current state' of the 'current mode'. With the new code I right click to change mode and then realize that I can't see the cursor and in making it viewable I might have to experiment a bit depending on it's actual location hence the drastic changes So IMHO the cursor should at least 'warp' to screen center point on mode change to 'minimalize surprise' before this new code is considered as a replacement for the existing default code. I also feel that some effort should be made to replace the previous 'autopositioning' mouse mode behaviour in that this is what the users are accustomed too even though they perhaps didn't recognize it happening. Note - I fly exclusively with either the mouse or the keyboard and rarely even have a joystick connected so I am perhaps more 'sensitive' to these issues then those who's primary interface is with the more 'exotic' devices. Keeping FGFS flyable with just the 'basic' input devices is IMHO a worthy goal. I and I am sure others too would be disapointed seeing us going backwards in this respect Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
