Relevant info: I’m running Haiku Beta 4 in vmware player.
When I implement a window based on a BView, and press alt+c on the keyboard, I don’t get a KeyDown event, just the KeyUp event. Is this to be expected?
The B_COMMAND_KEY flag is set in the flags returned by get_key_info.
Yes, I believe it is app_server that automatically eats those key down events but it has been a long time since I looked into it. Depending on what you are doing in your app then you may be able to use the AddShortcut() method for BWindow. Otherwise, I think the B_NO_SERVER_SIDE_WINDOW_MODIFIERS flag to BWindow() can be used to do that but I’m not sure. I know Emacs is capable of handling alt shortcuts but I haven’t looked into how it’s done.
It’s BWindow, not app_server; it just adds these and a few other keys via AddShortcuts in its constructor.
For most applications, you should not bypass this handling, but just handle the B_COPY/etc. messages when you receive them (as they can be generated other ways than just pressing the shortcut) to modify the clipboard.
But for specialized applications (e.g. ports of software from other OSes) where you really need the events nonetheless, you can bypass this in one of two ways:
calling RemoveShortcut to remove these and whichever other shortcuts from the window.
overriding BWindow::DispatchMessage and doing your own handling before BWindow has a chance to catch shortcuts. Note that this will also bypass most global shortcuts, including Print-Screen, Ctrl/Alt-Tab, and others!
You’re right that it’s in BWindow but I was referring to this code in Window.cpp which says that it eats all the events.
Ah, indeed. That method is called from DispatchMessage. So I guess the solution #1 I listed above isn’t viable after all.
I think that it is a bug. Global shortcuts should be handled globally (input_server filter?), not in each application individually.
Yes, probably. We should enhance Shortcuts preferences more and then move such default shortcuts handling to it.
I am writing a cross platform gui library to port over my various apps. So something generic would be nice.
For the moment I’m just catching the KeyUp event and making it the down event for consumers of the library. It’ll get some functionality working.
What does your “shortcuts” API look like? Depending on how high-level it is, you may not need to catch the “key down” events at all, but can instead just pass shortcuts to the BWindow via AddShortcut (or by specifying shortcuts on BMenuItems.)
If for some reason that isn’t viable and you really need to catch all shortcuts directly (as Qt or other toolkit ports must), you can override DispatchMessage. You can see an example of where I did that in Xlibe for reference.
At an application level window my menu loader scans the menu item resources and creates shortcuts from the specified shortcut string. However at an edit box level, it may need to operate independently from a window with a menu, like in some random dialog. So things like Cmd+C for copy still need to work. Traditionally I’ve just caught the key press event and handled that. I wonder whether B_COPY is sent when the user presses Cmd+C without an actual shortcut in the window’s menu?
Seems like that should be the way to work. Usually one expects things like copy & paste shortcuts to work everywhere, and not depending if some window/software implements it or not
Shortcuts can be defined independently of menu items with AddShortcut. Indeed the shortcut for B_COPY is one of them that is defined by default.