John P. Pfost wrote: > Hello Albrecht and Fabien. > > Before I continue I would like to say Thank You for your efforts on this > project, as well as the others who regularly contribute to the discussions, > fixes and support. Lots of hard work/discussions on UTF8 and documentation > especially.
You're welcome. > As Fabien has mentioned my intention with this patch was to mimic the actions > of the mouse, when you pushed then released a button with the FL_WHEN_CHANGE > attribute, using shortcut keys. As an example in my application I have four > buttons which move an indicator up/down left/right when one or more of the > buttons are pushed. Each push causes only a single callback, but the user > has the feed back that he is holding the button down. When the indicator > reaches the desired position the user can then release the button to stop the > movement. As an added benefit, using the short cut keys you are able to move > the indicator in the X/Y direction simultaneously, ie holding the SHIFT key, > Up Arrow Key and Left Arrow Key at the same time would move the indicator > towards the upper left hand corner of the screen. Thanks for your explanation of what you are doing. This make it much clearer to understand your intentions. This also shows to me, that your problem should be solved by a specialized widget that can handle the keyboard input just as you like. This doesn't mean that FLTK should not be improved, if it can be done, but whenever there are too many (combinations of) cases to check, there are always holes for bugs to slip through. IMHO, a universal toolkit like FLTK comes to its limits, if you want to have special handling of multiple input devices, or more than one key at a time. FLTK is great in translating "primitive" events (in the sense of simple, basic) in a platform independent manner, but for complex event interaction, the programmer is in charge. FLTK allows you to derive your own widgets and do all keyboard and mouse handling you like. As you saw already, you would need some state variables that show you, which event has happened before (shortcut, key still pressed, mouse button pushed, released again, ...) and which combinations you like to handle. If you write your own handle() method, you can query the (modifier) key states, just like you want, but I think that you can't reliably test, if multiple other keys (alphanumeric, or cursor keys) are pressed. Try under Windows (I used notepad to use only MS-supplied programs): press and hold A, until the A repeats, then press and hold B too (now B repeats), then release B. What should happen? Should A repeat again? It doesn't. Maybe you could use a timer and check the key states (query the OS or X server) but that is something that FLTK does _not_ do (except for the modifier keys, IIRC). > There are a couple of anomalies I have noticed with this patch, but they are > unusual situations. If you use the mouse to push a button then initiate the > short key, then release the mouse button the action continues. This is what > I believe should happen. Which "action" continues? Pressing keys is a single event. Continued actions can only happen, because the OS repeats the key (simulates multiple key presses). > If you initiate the short cut then push the mouse button then release the short cut the action stops. Again, a mouse push (not a drag) is a single event. It happens exactly once when you push the button. After releasing the key, there are no events created by the system, and FLTK can't do anything. > This occurs because the mouse push has no idea that the short cut has also been used. No, see above. There are no events. > The short cut does know because of value_ . But only because the system creates repeated keyboard events, otherwise nothing would happen. > I was tempted to start using bit values in value_ to indicate if multiple > methods had activated the button, ie short cut and mouse push, but I felt > this would violate the intended use of value_. That's what I wrote about before. You need specialized state variables to track all changes. This is beyond the scope of a toolkit like FLTK. > At some time in the future it might be worth the effort to revisit how interactions with buttons, and any other widgets which are used to receive user input, are done. Especially with multiple input methods( mouse, keyboard, touch screens eye trackers, etc) becoming available all the time. IMHO, FLTK can "translate" the events, but you must do the complex work yourself... > The other anomaly I noticed the other day is if you initiate the short cut > using the key first then then pressing the state key next, the short cut does > not work. As an example pressing the UP arrow key then pressing the SHIFT key > will not work, but pressing the SHIFT key then the UP arrow key works. Will > have to take a look at this. This sounds like something FLTK could indeed do, but OTOH we're not alone with this. Probably this is even intended, and should not be changed. Imagine you are editing a text in a text editor. Pressing ALT-X means "eXit". Okay, you press ALT, then X, and you get the menu, or the editor "kicks you out" immediately. But if you want to write the letter X, how long would the editor wait to display the X, before it knows, if you like to write a lower case or upper case X (with SHIFT), or if you would like to press the ALT key to get the exit menu instead? No, IMHO pressing the modifier keys first is necessary. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
