There is no nice (or is it even official?) way of detecting and handling the media keys on the user’s keyboard. One can intercept events with type NSSystemDefined and subtype 8 in -[NSApplication sendEvents:], but this has major problem: any other applications that listen to the media keys will receive these events too. This means for example that if only Spotify is running and you want to pause your music, iTunes will start when you press play/pause. If you have VLC running in the background, it will also start playing.
Apple has solved this problem internally by having their media key using applications cooperate and resign media key controls to the application that was in the foreground most recently. However, there is no way for third party applications to join this cooperation.
This class is smart enough to resign the media key event tap whenever another application that we know will want to use the media keys becomes active, and keeps track of which media key using app was recently started.
If everyone uses this class, and everyone add each other’s bundle ID to that list of whitelisted bundle ID’s, we’ll get nice behavior from all apps. An even better solution would be if Apple provided a way of acquiring the media keys.
Maybe half of Spotify’s dev team is completely addicted to Minecraft. We spent maybe six hours last night making this on our own multiplayer server. It doesn’t come through very well in a still picture, but that thing there is *huge*. (For perspective, this is from during the construction process (or rather the first; we redid the whole thing after that due to mistakes))
I despise using web apps. The only ones I’ve found that are even at least useful are made by Google, and Google’s web apps are as aesthetically pleasing and user friendly as a Windows 98 shareware app. But even if they were made with the same care and attention to detail as Mac apps by Cultured Code or Omni Group, they’d still have a long way to go before being as useful and productive as a native desktop app, because they’d be missing some essential features the browser can’t give them. This is my list of these features, as I think of them.
Undo/redo for non-text things (that is, JS hooks for undo)
Pasteboard for anything but text. Important: application-specific objects like e g “calendar event” in an iCal like app, not just a generic group of common media (like pictures, audio, video, styled text, …), although that would be really nice as a stop-gap measure
Host application menu integration, with a standardized way to handle keyboard shortcuts
A windowing concept of “application” with several windows and OS hooks (i e dock icon or task bar group)
Context menus
Some document store model that is shareable between web apps. Example: if I have an image, I want to be able to open it in both a nice editor, and a nice viewer, which might be two completely separate apps by completely separate vendors.
There is one things a web app can’t *ever* have without doing tons and tons of work, and that is behaving like a native app. Google has fake context menus in their apps for example, but they don’t contain the options normally available when context-clicking text in Mac OS; for example, right clicking a word in Wave won’t let me look it up in the dictionary, speak it, nor do spelling corrections on it. Moving down a list using arrow keys is a very standard feature in list views in native apps; in Gmail this is an advanced feature you have to turn on, and you have to use letter keys to do the navigation (j, k for down, up).
I originally made this list in Wave over a year ago; moving it here since Wave is dying. The list is made a little bit antique by the introduction of the iPad; three of the items might now fall under the category of “things a native app might not need”.
The big wins you get with web apps are all in deployment. Deploy-once, instant upgrades, cross-platform. You can argue that sacrificing usability for easier deployment is worth it, but I’d rather do it the other way around.
Michael Casteel is my new hero! Got mom a 13" MBP a while ago to replace a Performa, but she missed Klondike and none of the other osx card games I had found were as good. Turns out Casteel ported his original Klondike to OS X! It’s originally a game for the Plus, I hadn’t even considered that he still worked on it.
We were updating our app’s graphics for the gorgeous screen of iPhone 4 the other day and it was a pain to update all the 163 PNG files we had and not to miss a thing.
So, I’ve come up with a simple Ruby script that checks that for each @1x image you have a properly sized @2x image.
Man, such a life saver. sudo gem install ios-png-check is the path to bliss.
