From: Jun T. <tak...@kb...> - 2014-11-19 02:48:28
|
On 2014/11/19, at 1:33, sfeam <sf...@us...> wrote: > Are you sure this is not a property of your keyboard rather > than a property of your operating system? Yes. Please look into the following Qt document: http://qt-project.org/doc/qt-4.8/qt.html#KeyboardModifier-enum especially, the Note section says "The KeypadModifier value will also be set when an arrow key is pressed as the arrow keys are considered part of the keypad." See also the "Listing 5-4" in the following Apple document: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html > What about keyboards that have both keypad arrows and separate > arrow keys? I tried four keyboards, two of them have numeric keypad but the separate arrow keys are treated as part of the keypad. > The QtGnuplotScene.cpp.diff patch appears to be backwards > from what you describe above. If it detects __APPLE__ it > removes the keypad modifier, rather than adding it. Yes, it is the intended behavior. When the left arrow key is pressed, the condition if (event->modifiers() & Qt::KeypadModifier) is TRUE, and, before the patch, GP_KP_Left is generated. But no action is bound to GP_KP_Left by default. After the patch, GP_Left is generated, which is bound to builtin_rotate_left by default (in mouse.c). Or we can bind builtin_rotate_left to GP_KP_Left in mouse.c (without patching QtGnuplotScene.cpp). |