I have created an NSStatusBar cocoa application which sits in the system status bar.
I want to assign a hotkey so that when pressed it toggles my applications and show the menu.
Is this possible?, In my searching and experimenting I have found a few different ways of assigning global hot keys that can be pressed when your application is in the background but I can't find any way to problematically make the menu show.
Is this possible?, If anyone thinks a way of assigning a global hotkey is best please post it.
Thanks.
One of the hotkey tutorials I found was on http://dbachrach.com/blog/2005/11/program-global-hotkeys-in-cocoa-easily/ for anyone interested.
If you're targeting 10.6+, there's some new API for NSEvent that can do global hotkeys. For more information, check out this awesome blog post: http://cocoakids.net/global-hotkeys-in-cocoa-on-snow-leopard
EDIT (a long time later)
Tooting my own horn a bit: I could never get things like PTHotKey and other libraries to work the way I was expecting, so I eventually gave up and wrote my own HotKey wrapper. It has a very simple API (you give it a key code, modifiers, a target, and an action), that even supports fun things like 10.6's blocks. You can download the source here: http://github.com/davedelong/DDHotKey
There is an actual hotkey API, which still exists in Snow Leopard and is available in 64-bit. It's designed specifically for this purpose, unlike the NSEvent methods, which are essentially just a block-based wrapper around CGEventTaps.
The difference is that the NSEvent methods (or CGEventTaps directly) make you look at every event that comes in, whereas the hotkey API only calls your function when the user presses your hotkey.
Related
Ctrl+Escape is a global Windows shortcut for opening main system menu. But I would like my Qt application to use this shortcut without triggering Windows main menu. I know it is probably a bad idea to override system shortcuts in general, but I would like to use this shortcut is a very limited use case.
This usecase is as follows. I have a popup window containing several rows or items. This window is opened by Ctrl+Tab and while the user holds Ctrl and keep pressing Tab, the current rows are cycled through. When the user releases Ctrl, the current row is used for some operation... But sometimes it happens that user presses Ctrl+Tab and then realizes he does not want to continue. He usually presses Escape while still holding Ctrl. And then it triggers Windows system menu and normal user gets confused, choleric user get angry... which is a bad thing. In other words I would like to be able to close the popup window when user presses Ctrl+Escape. How to do that? It is even possible?
If I write the code using this shortcut like any other short, it does not work and it always triggers Windows main menu.
As I understand it, Qt will typically not receive the key event if the underlying window system has intercepted it. For example even QtCreator cannot override system-wide shortcuts.
This question is almost a duplicate of: C++/Qt Global Hotkeys
While that question is asking specifically to capture shortcuts in a hidden/background application, I think the basic concept is the same -- capture shortcuts before the window system processes them.
From that answer, UGlobalHotkey seems pretty good, and the How to use System-Wide Hotkeys in your Qt application blog post could be useful for your limited-use case (but read the comments on that blog post about fixing the example).
Also found:
https://github.com/mitei/qglobalshortcut
https://github.com/Skycoder42/QHotkey (looks like a more detailed version of above)
Soon I will have to work with OS X and tools like hammerspoon are missing some important capabilities for me. I need to be able to intercept keyboard and mouse events completely from the focused application. Say I ctrl+alt+apple+left_click on an application, I don't want the application to know about that left click. So far the only thing I came up with was to build a transparent fullscreen application, though I'm not sure how feasible that is yet.
Any better idea or hints how to go about this in a language of your choice?
Thanks!
You will need to create an event tap. However, the application will have to run as the root user, or the user will have to authorize that the application has been granted rights to accessibility features.
Apple's documentation can be found here.
Interestingly enough, I am in the process of writing a blog post about how to use event taps (including an ObjectiveC API that I wrote for my own use), but the post won't be made available for another week or so.
Hey guys, I've finished my little calculator and now what I want to do is this:
I want to be able to run it in the background until I press, say, Control + C and then have it open...is this possible in OS X? I recall it being pretty simple in Windows...where should I begin to look?
I feel like it will involve running as a service or something...
One solution is to have your calculator provide a Service. A Service can be assigned a global key combination. When the combination is pressed, your calculator application can open, and ideally, perform a task on the user's current selection.
To assign a service a specific key combination see:
System Preferences > Keyboard > Keyboard Shortcuts
An alternative approach is to create a background application. This application can register for a global hot key combination. When the combination is pressed, the background application can launch your calculator.
Maybe a setting up a global hotkey.
I found and use the example here. Which works really well.
There where mixed thoughts on if apple would fully deprecate the Legacy API used,And I think
there is a new API. But for the life of me can not find it again.!
Ah! found it it was in the NSEvent Class Reference : * addGlobalMonitorForEventsMatchingMask*
Using the Apple OS X Cocoa framework, how can I post a sheet (slide-down modal dialog) on the window of another process?
Edit: Clarified a bit:
My application is a Finder extension to do Subversion version control (http://scplugin.tigris.org/). Part of my application is a plug-in (a Contextual Menu Item for Finder); the bulk of my application, however, is in a separate daemon proces. For several reasons, we've chosen to put virtually all the code into the daemon; the plug-in only defines the menu itself, and Apple-Events over to the Daemon.
Sometimes, the daemon needs to prompt the user for further information. It can toss a window on-screen for this, but that's disruptive (randomly positioned), and it seems to me the work flow here is legitimately modal, for example "select a file, pick 'commit' from the menu, provide commit comments, do the operation."
Interprocess cooperation (such as passing a reference of some kind) is acceptable: both processes are mine, but I want to avoid binding the sheet's code into the primary process.
Really, it sounds like you're trying to have your inter-process communication happen at the view level, which isn't really how Cocoa generally works. Things will be much easier if you separate your layers a bit more than that.
Why don't you want to put the sheet code into the other process? It's view code, and view code is inherently process-specific. The right thing to do here is probably to add somewhat generic modal-sheet support to your plugin code, and an IPC call that your daemon can make to summon that code. Trying to ship view objects over to the remote process is going to be nightmarish if you can make it work at all.
You're fighting the frameworks with this approach.
You can't add a sheet to a window in another process, because you have at most only the most restricted access to the windows in the other process.
Please don't do this. Make the interaction nonmodal if at all possible. Especially in something like a commit, it's much nicer to be able to browse around your files while you're writing commit comments.
OS X does have window groups, but I don't think they can (easily) span applications.
Another thing to consider is that in OS X it's possible to have many Finder windows open on the same folder (unlike in OS 9). Even if you did have sufficient privileges/APIs to add a sheet to a Finder window, it's not like the modality of that window would prevent the user from being able to continue working with the files.
(My personal opinion as a long-time Mac user is that this kind of interaction would drive me right up the wall.)
I'm writing a routine to provide user definable keyboard short-cuts for any menu item in my Windows Mobile 5 application, which is in C++/MFC. To do this I am getting all of the available menu command IDs, and using the CWnd::PostMessage(WM_COMMAND,MyMenuID) to post it to the application. I use this technique to good effect elsewhere for inter-thread comms, but not with menu command IDs. Any ideas why this doesn't work. The app is document view, and I have tried posting to the CMainFrame and CView derived windows. I could write a god awful switch statement but I feel posting a message should work.
Edit: Ok, i've tried a number of things, including suggestions from this post, to no avail. Big ugly switch statement it is for now, I'll update again if i find anything better.
The only reason I can think of is the message is going to the wrong window. Don't forget that not all menu commands are always processed by a particular window. Some menu commands like Cut are usually processed by a view window. Others are processed by frame windows and some possibly by the application object.
Hope this helps.