Input Managers and Leopard
March 23rd, 2007
In this Ars post on Leopard’s ship date (I’m pretty sure it will be around WWDC, BTW), the paragraph that gets the most attention in the comments is this one:
One more tip we got regarding Leopard, is that InputManager plugins are no longer allowed. That’s right… no more little hacks from anybody besides Apple. No more Apple menu hacks. No more Safari plugins. (InputManager is not exactly the same as APE, by the way.) “Apple isn’t really broken up about it since InputManagers were often used for nefarious purposes anyway,” our sources said, but the loss of InputManager control will break a lot of shareware and commercial software that currently makes use of that control.
I have to say, this will be a huge help to me. The trouble with Input Managers is that they load into every application, and the problem with that is, they are almost always involved in the crash reports I receive for KIT. The telltale sign is when the crash is happening entirely in Apple code, sometimes drawing standard widgets, sometimes just as part of the run loop, with the Input Managers listed below.
The trouble is that KIT gets the blame. I’m not sure why KIT is so susceptible to these, as Feeder hardly seems to get affected, but I suspect it’s for a combination of reasons.
Firstly, the sort of people who use apps use KIT like the enhancements these Input Managers provide. Secondly, KIT uses a whole heap of Apple frameworks and is always swapping views in and out. Finally, KIT is very multithreaded, scanning for changes to files, indexing, searching, etc. Maybe some of the problems are due to the way KIT is designed, but I have no way of finding out.
I have no issue with people running Input Managers, as long as they accept that this means their set up is unsupported when crashes occur.
The simple fact is the application works perfectly on a regular system and I can’t fix problems in code that aren’t mine, so less hour spent sifting through crash reports that have nothing to do with me, the better.
March 31st, 2007 at 3:22 pm
Well said, Steve. It’s unfortunate that Input Managers often become synonymous with “Plug-ins” from the user’s standpoint, since they accomplish their ultimate behavioral goals utilizing unsupported and dangerous techniques such as external code injection and method swizzling.
We’ve had the same experiences with Camino, specifically among bug reports targeted at 1.1 beta. One of our developers recently wrote a post that parallels yours, which you can read at http://www.escapedthoughts.com/weblog/camino/P070227caminohacks.writeback.
By the way, I’m a happy user of Feeder; It’s another example a well polished application that can be engineered by a single, independent developer working with awesome tools and frameworks.
April 2nd, 2007 at 11:51 pm
Thanks Sean – that’s a great post!
And thanks for the Feeder comments too.
July 10th, 2007 at 5:14 am
Your viewpoint is very understandable… I’m sure it must be a pain to have your software blamed by users for a bug in some other developer’s InputManager or APE or SIMBL or ContextualMenu or whatever. However, the fact is that Cocoa is designed to be an object-snappable framework, and this is a huge advantage over other application frameworks from the user’s viewpoint.
Cocoa apps must be able to load libraries developed by other authors if they are to prove optimally useful. Developers need to be aware of the various libraries that users might be adding to their setups and make authors who aren’t using the Cocoa APIs appropriately aware of their errors. It kind of needs to be a cooperative venture, rather than each developer viewing their application as some kind of island that can exist on its own.
Again, I know it’s tempting to view badly written code that sends users running to you with complaints as the fault of APIs like Input Manager (which is going away anyway but will likely be replaced with something else), APE, or SIMBL, but the problem is the author of the badly written code… not the API itself.
As a user, I find the ability to add functionality to all of my Cocoa apps a huge advantage over the prevalent “silo app” approach. Likewise, I’m a very big fan of APE and have never had any problem running them… it’s quite easy to disable a given APE in a particular app if it becomes a problem, and it’s easy to tell users how to do that. Unsanity has built a beautiful API for adding functionality to Mac OS X that Apple has left out, and there are scores of useful APEs out there from third parties… nearly all of them free (except those from Unsanity).
Just wanted to make that point. Oh, and the reason I happened upon your blog is that I’ve read that Apple is including a new API for method swizzling in Leopard, and I ended up here through a Google search.
Cheers,
Leland
Musings from Mars
July 26th, 2007 at 5:38 pm
The crash behaviour you describe actually sounds like a memory smasher. This could be the fault of an Input Manager, or it could be a latent bug in your code that is simply being tripped by an Input Manager.