If your new to Cocoa you've probably not heard of Carbon, on the other hand if you've been developing for the Mac for a while now you've probably at least heard of Carbon and if you're really experienced you've probably used carbon. If you've used carbon at all this article really isn't for you. What I want to do is gently introduce you to carbon events, the 1 scenario where we'd use it for in terms of cocoa apps, why Cocoa Events can't handle this one scenario and why Carbon Events can, and how to implement it in a Cocoa Application. Why Carbon Events There is a specific scenario I had in mind as to why you would use Carbon Events ( actually if you have a Cocoa app it's a you have to use Carbon Events), the scenario is this: you have a Cocoa application and you know your customers will be running it but it will not be the active application running in the foreground, your customers may be looking at Mail, NetNewsWire, Xcode, etc basically some other application than yours and yet you still want to receive a keyboard shortcut key pressed event. How do you do this? Not with Cocoa, in its current form it's literally impossible. Here's why Cocoa Events works as such, according to the Cocoa Event Handling Guide it says "In the main event loop, the application object (NSApp) continuously gets the next (topmost) event in the event queue, converts it to an NSEvent object, and dispatches it toward its final destination. It performs this fetching of events by invoking the nextEventMatchingMask:untilDate:inMode:dequeue: method in a closed loop. When there are no events in the event queue, this method blocks, resuming only when there are more events to process." It then goes on "After fetching and converting an event, NSApp performs the first stage of event dispatching in the sendEvent: method. In most cases NSApp merely forwards the event to the window in which the user action occurred by invoking the sendEvent: method of that NSWindow object. The window object then dispatches most events to the NSView object associated with the user action in an NSResponder message such as mouseDown: or keyDown:. An event message includes as its sole argument an NSEvent object describing the event."
So in other words the NSApplication has an event queue and receives an event (1) converts it into NSEvent objects (2) which it then forwards to a Window (3) which then dispatches the event to the view associated with the user action calling on it -mouseDown:(NSEvent *)event, -keyDown:(NSEvent *)event, etc (4). This is great, but if our application is running in the background there is no way our Window will receive events. Cocoa Events simply does not allow for a regular cocoa application to be in the background and receive keyboard events. Now I could go on to further explain NSResponder and how it events could then go onto the menu's after exhausting all possible views in a window that could respond to an event, but that's another article onto itself. The point is our app is a regular cocoa app and it has a window and menu's, but we know our application is not going to have focus and thus won't have a window that can forward events or even application menu's to receive events, but we still want to receive an event and invoke some sort of functionality. There are plenty of examples of this: OmniFocus has a quick entry window which you can invoke from anywhere, applications like Quicksilver use Carbon Events so you can invoke them anywhere from in Mac OS X. These are both Cocoa applications, but they depend on Carbon Events to give them notifications of global keyboard shortcut events. Conceptually Carbon events is vastly different from Cocoa Events. When I first finally got a Carbon Events example working it seemed very strange compared to Cocoa Events, it was more like there is a stream of events going by in the system and you install something to indicate a interest in a particular kind of event. If that event matches the specific event you are looking for then your code is called and you have a global keyboard shortcut. So how do we do this? Setting up a project In Xcode, go ahead and create a new Cocoa application. At this point if you build in go all you will have is a small window and an application that does nothing. Now go to File->New File and create a plain Cocoa class and call it AppController. Then click on the disclosure triangle by the Frameworks folder and then right-click on Linked Frameworks and go to Add -> Existing Frameworks and in your SDK add "Carbon.Framework." At this point this should be all you have for AppController.hThursday, March 26, 2009
Global Keyboard Shortcuts with Carbon Events
Posted by
Colin Wheeler
at
9:17 AM
14
comments
Sunday, March 15, 2009
Book Review: Pragmatic Thinking & Learning
In what may be become the first in a series of reviews, I thought i'd share some of my thoughts and some insights into various Computer Science/Programming/Developer related books. I am always reading something so I thought i'd provide some thoughts on these books as I read them. Pragmatic Thinking & Learning is a book that I came across in an unusual way, basically Bill Dudney said he was reading it on twitter, posted a couple updates on his progress and then never really mentioned it again. I was getting done reading Predictably Irrational and the book left me very fascinated about Psychology. I have taken Psychology class, but Predictably Irrational brought it down to a practical level and showed how it applied in the real world with behavioral economics. In that same spirit Pragmatic Thinking & Learning is to Programming & Learning what Predictably Irrational is to behavioral economics. It's a fascinating journey through behavioral theory, cognitive science, neuroscience and some psychology, all while you are learning how your brain is wired and how it all works. Don't let these science terms make you think it's some boring study on how our brains work, as the title says it's Pragmatic Thinking & Learning. In essence it takes you through how your brain works and then quickly applies it to the real world and offers more of a framework for how you can begin to apply the principals presented. Through the tips and studies in this book you gain a lot of unique insight into problem solving, for example how do you teach someone how to play tennis with only 20 minutes of time? One of the things that makes this book somewhat unique is that it forces you to stop every so often and do an activity or think about something. For example I meditated for 5 minutes today, where I don't think I've really ever been instructed on meditation, and I liked doing it so i'll probably continue trying meditation for a while and observe what differences it makes in my day. It's also not just the author making a case for an opinion, there are many citations throughout the book to external resources or studies on a particular subject. It offers some very good tips on things from how to keep yourself organized, how to think out solutions to problems, how as a developer you can try and recover from being interrupted when your in "the zone" and many other things like that. I was surprised when I saw the Rubber Duck debugging technique online one day and then came to read about it later that evening in the book. The book presents a case for something and then tries to get you thinking and get you involved in actively applying that to your situations. My only complaint is the author mentions using a personal wiki to keep things organized and keeps showing he is on a mac and never mentions VooDooPad which I use everyday. I got started using VooDooPad as a way to keep my School notes organized and now I use it for a lot more things, including notes about Cocoa, specific Classes, personal things,etc, it's essentially a Wiki in a convenient self contained document. Overall it's a nice collection of information on how our brains work, techniques to solve problems, how you can learn information or a skill faster and find techniques that work better for you individually. It's been a surprisingly good read and I am glad I bought it because Im sure I'll reference it from time to time from now on.
Posted by
Colin Wheeler
at
10:25 PM
0
comments
Labels: Book Review