pbfy0 / visvis

Automatically exported from code.google.com/p/visvis
Other
0 stars 0 forks source link

Proposal: Report modifier keys with each event. #21

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Right now, visvis gets notified of changes in modifier keys through keydown and 
keyup events.  visvis is responsible for keeping track of the status of the 
modifier keys by catching these events.

Unfortunately, this fails when the modifier key press events go to a window 
other than a visvis figure.  For example, if I am entering commands into a 
terminal that affect a visvis figure and I then decide I must translate the 
axes, I will press Shift and then left click and drag on the figure.  However, 
keyboard focus was on the terminal when I pressed Shift, so visvis never gets 
the Shift keydown event, and the axes rotate as I drag.

In GTK, every event comes with a key mask that gives the state of the modifier 
keys.  I'm sure the other backends do something similar.  I propose that this 
information be passed along in the visvis events and used to determine the 
response to these events.

Some ideas on how to do this:
1. Give BaseEvent separate shift, alt, control, etc attributes to be set to 
True when those keys are down.
2. Give BaseEvent a modifier attribute containing a tuple of pressed modifier 
keys.
3. Give BaseEvent a key mask.
4. Make a Modifiers class to keep track of these things, and give BaseEvent an 
instance of this as an attribute.

I think I prefer 2, but I haven't really thought about it much.

Original issue reported on code.google.com by rschr...@gmail.com on 16 Mar 2011 at 2:13

GoogleCodeExporter commented 9 years ago
Good idea. It would make a lot of code easier too. We should make sure that 
every backend allows this. I know that Qt does.

I prefer 2 also, you can then do something like:
if vv.KEY_CONTROL in event.modifiers:
    ...

Original comment by almar.klein@gmail.com on 16 Mar 2011 at 10:44

GoogleCodeExporter commented 9 years ago
If there is a backend that doesn't support this, it could try to keep track of 
the modifier state from the keydown and keyup signals.  It wouldn't be any 
worse than the current situation.

Original comment by rschr...@gmail.com on 17 Mar 2011 at 2:45

GoogleCodeExporter commented 9 years ago
Good point.

Original comment by almar.klein@gmail.com on 17 Mar 2011 at 8:32

GoogleCodeExporter commented 9 years ago
I've started work on this in the modifiers branch.  It's working with GTK and 
WX at the moment. I don't have Qt or FLTK installed, so it'd be easier if 
someone else could get them working.  I thought we should hold off on merging 
until all are working.

Original comment by rschr...@gmail.com on 18 Mar 2011 at 12:58

GoogleCodeExporter commented 9 years ago
Implemented it for Qt and fltk. Wow, that was easy :)

Tested on some interactive apps of mine, and they still work (using the old 
approach).

Original comment by almar.klein@gmail.com on 21 Mar 2011 at 3:28