[Super Mario]

Super Mario is annoyed with column view. When Super Mario selects an avi or other multimedia file that isn't supported by Quicktime the Finder beachballs as it waits to see if it can preview the item.

Super Mario thinks it would be a good idea if Finder previews didn't run off Quicktime alone. Most of us have VLC installed. Why can't Finder previews use the codecs installed with VLC or Windows Media Player to preview items Quicktime can't?

We also have Word installed. I would like to see previews of my Docs. I also want options to make my previews bigger so I can see the first page of PDF and Doc files.

When we install VLC, Windows Media Player, Office, etc the Finder should be updated to be able to preview those files. We need a Finder that allows plugins to be installed by third parties so we can have those features. Beachballing is so 1986.

[TETENAL]

QuickTime supports plug-ins. The makers of VLC and Windows Media Player didn't write a QuickTime plug-in. What makes you think they would write a Finder plug-in?

[Spheric Harlot]

Originally posted by TETENAL:
QuickTime supports plug-ins. The makers of VLC and Windows Media Player didn't write a QuickTime plug-in. What makes you think they would write a Finder plug-in?

The Finder just uses QuickTime to generate the previews.

-s*

[Luca Rescigno]

At the very least, it would be nice if the Finder would learn to not try to preview movie files of a certain type that it can't play. If it tries, and fails, then it should pop up a dialog box asking if you want it to stop trying to preview movie files of that type or not, and you can change it by using the Get Info window.

[Big Mac]

Bob Dole doesn't like this one bit, no sir, Bob Dole does not.

[TETENAL]

Originally posted by Spheric Harlot:
The Finder just uses QuickTime to generate the previews.

Please understand what I wrote.

QuickTime already supports plug-ins. The makers of VLC and Windows Media chose not to write a plug-in for QuickTime. If the Finder supported plug-ins, what makes you think they would write a Finder plug-in?

[chris v]

chris v is annoyed with Super Mario referring to himself in the third person. You don't have to have a stupid gimmick to have a discussion here.

[Spheric Harlot]

Originally posted by TETENAL:
Please understand what I wrote.

QuickTime already supports plug-ins. The makers of VLC and Windows Media chose not to write a plug-in for QuickTime. If the Finder supported plug-ins, what makes you think they would write a Finder plug-in?

nothing.

my point was that the finder DOES support plug-ins - QuickTime plug-ins - for previewing.

is all.

[Super Mario]

Super Mario is saying that Preview should not be owned by Quicktime. Previews should be generated by individual or compatible applications.

Longhorn is ahead in terms of thumbnails and previews (that's about all...and hardware acceleration). Super Mario says OSX must be there. Tiger preview doesn't show any signs of it so far.

Super Mario is refered to in the third person because the poster is his secretary: a reformed mushroom.

[K++]

Originally posted by Super Mario:
Super Mario is saying that Preview should not be owned by Quicktime. Previews should be generated by individual or compatible applications.

Longhorn is ahead in terms of thumbnails and previews (that's about all...and hardware acceleration). Super Mario says OSX must be there. Tiger preview doesn't show any signs of it so far.

Super Mario is refered to in the third person because the poster is his secretary: a reformed mushroom.

the QT API is a well tested API that is used A LOT of places in OS X, also QT isn't solely responsible for previews, simple text based tpyes are also previewed. But PDFs do show you a whole page, the preview is just to small to make out any text.

Lastly Longhorn isn't doing anything that Finder isn't, except for... you know... EXISTING. What Explorer does this currenly is that it relies on the DirectVideo API that it uses for Media Player and the like, since all windows media programs just add codecs to windows, it can preview anything your installed apps can. It's not better or worse than Finder's setup, only difference is everyone wrote thier application as codecs that use the default Video API. DivX/VLC/Real Player/etc.

[Angus_D]

Originally posted by K++:
the QT API is a well tested API that is used A LOT of places in OS X, also QT isn't solely responsible for previews, simple text based tpyes are also previewed. But PDFs do show you a whole page, the preview is just to small to make out any text.

Yeah, but unfortunately the QuickTime component API sucks hardcore donkey gonads.

[Maflynn]

Originally posted by Super Mario:
Longhorn is ahead in terms of thumbnails and previews (that's about all...and hardware acceleration). Super Mario says OSX must be there.

Well if Longhorn is so advanced just head down to compusa and buy a copy, oh wait its not published and it won't be for a couple of years. Which OS is more advanced, well since longhorn not available, other then betas I suppose OSX is.

[Uncle Skeleton]

Originally posted by Super Mario:
When Super Mario selects an avi or other multimedia file that isn't supported by Quicktime the Finder beachballs as it waits to see if it can preview the item.

We need a Finder that allows plugins to be installed by third parties so we can have those features. Beachballing is so 1986.

Speaking of plugins, if you would just install the DivX plugin you wouldn't have this problem (with AVI files, and I highly doubt you have it with any other movie files)

[Angus_D]

Actually, IIRC NeXT's Workspace Manager could take plug-ins to handle previews, the problem is just that OS X took a huge step backwards.

[IamBob]

Actually, IIRC NeXT's Workspace Manager could take plug-ins to handle previews, the problem is just that OS X took a huge step backwards.

Even if it hadn't had its own plugin system/API you would've been able to do it. Remember, there was no Carbon back then and InputManager bundles/plugins can do all sorts of nifty things in Cocoa apps.

I wrote one for Safari in less than an hour a week or so ago. My brother wanted to be able to edit a page's source in Safari and load it in a new window or tab.

I added a little reload button to the title bar of the View Source window (where the pill would be if it had a toolbar) and made the text view editable. While I was in there I changed Safari's icon, to show that it's modified w/ a plugin. And a hidden pref keeps the plugin from loading for anyone but him.

...I just wish it was that easy to extend Carbon apps.

[lenox]

...and I wish the Finder wasn't carbon. How long do we have to wait?

[TETENAL]

Originally posted by lenox:
...and I wish the Finder wasn't carbon. How long do we have to wait?

The Finder will always be Carbon and there is nothing wrong with that.

[IamBob]

The Finder will always be Carbon and there is nothing wrong with that.

Are you serious?

The Finder is broken* and has been since the Public Beta. Half the reason is because it's Carbon -- if it was a Cocoa app a third-party would have fixed it for us years ago (w/ InputManager plugins).

Not to mention that it's impossible to gracefully replace it on a per-user basis, which "the most advanced operating system in the world" should allow.

* Half opinion, half fact, not a point worth arguing.

[Sven G]

BTW, when will we have a tabbed Finder? Would be very convenient, from a practical point of view (despite of what the browsing vs. file managing separation purists say), and even elegant...

[TETENAL]

Originally posted by Sven G:
BTW, when will we have a tabbed Finder?

The Panther Finder is tabbed.

[Angus_D]

Originally posted by IamBob:
The Finder is broken* and has been since the Public Beta. Half the reason is because it's Carbon -- if it was a Cocoa app a third-party would have fixed it for us years ago (w/ InputManager plugins).

Uh, you don't see third parties fundamentally rewriting bits of applications with InputManagers. The reason that it's broken is because it's a poorly written application, not because it's Carbon or Cocoa.

[Millennium]

Originally posted by Angus_D:
Uh, you don't see third parties fundamentally rewriting bits of applications with InputManagers. The reason that it's broken is because it's a poorly written application, not because it's Carbon or Cocoa.

Angus is right; the Carbon/Cocoa distinction is meaningless. It is true that Apple threw away a perfectly good codebase to rewrite the Finder from scratch, and much effort was wasted because of that. But the Finder's problem was that it was a halfhearted effort, not that it used Carbon.

In any case, the Finder does support preview plug-ins, and not just through QuickTime. This feature is exceedingly little-known, and I've never seen any documentation covering it at all, but there is exactly one app out there which uses it: AppleWorks. The one and only thing Apple did right with AppleWorks on OSX was to provide a Finder preview plug-in with it, and the they didn't even bother to document how it was done. As a result, I have no clue where to begin on how one might write one. I only know that it's there, somewhere.

[BuonRotto]

Originally posted by TETENAL:
The Panther Finder is tabbed.

Uh, I've never seen this, but then again I'm not part of the "in" crowd, aka, an ADC member. That would say a lot about the direction of the Finder. Hope this doesn't derail the thread too much, just that this comment popped out at me.

on-topic: Does the Carbon API offer any sort of plug-in structure like Cocoa apps seem to have avilable to them? I can see why depending on QT for previews is too limiting, when you can make good use of previews for things like InDesign or Quark layouts, not to mention Word documents. If you could see a preview like how you can with a .rtf doc now (which isn't so elegant really, but it's a decent attempt to let you read some of the file's content before opening it), then it would be great for even text editors and WPs to have previews too. I'm not saying that Apple should be responsible for third-party file type previews either, just that there are some occasions when QT seems like a narrow-minded choice.

Of course, some apps do create their own previews and preview icons for the Finder. PS still does this despite being somewhat superfluous with some file types, SketchUp for example tags a little pic of the model to the file icon, and Stone's Create is about to get preview icons because the developer spun their own way of doing this. But a unified way for developers to implement previews for their filestypes would be very handy assuming third parties would take advantage of it.

[Millennium]

Originally posted by TETENAL:
The Panther Finder is tabbed.

Huh? I've never encountered a tabbed interface for the Finder. Could you elaborate on how this works?

[Millennium]

Originally posted by BuonRotto:
Uh, I've never seen this, but then again I'm not part of the "in" crowd, aka, an ADC member. That would say a lot about the direction of the Finder. Hope this doesn't derail the thread too much, just that this comment popped out at me.

He seems to be talking about the Panther Finder, not the Tiger Finder.

on-topic: Does the Carbon API offer any sort of plug-in structure like Cocoa apps seem to have avilable to them?

That sounds like Apple's CFPlugin framework. I don't know if the Finder uses this -it's a very old API, but the Finder may predate it- but there is definitely something.

[TETENAL]

Originally posted by Millennium:
Huh? I've never encountered a tabbed interface for the Finder. Could you elaborate on how this works?

You press ⌘T to add a folder and then switch between them in the bar on the left.

[Chuckit]

Originally posted by BuonRotto:
I can see why depending on QT for previews is too limiting, when you can make good use of previews for things like InDesign or Quark layouts, not to mention Word documents. If you could see a preview like how you can with a .rtf doc now (which isn't so elegant really, but it's a decent attempt to let you read some of the file's content before opening it), then it would be great for even text editors and WPs to have previews too. I'm not saying that Apple should be responsible for third-party file type previews either, just that there are some occasions when QT seems like a narrow-minded choice.

QuickTime is only responsible for previewing QuickTime-supported formats. It's not QuickTime that's previewing RTFs. So I don't see how QuickTime's limitations are relevant to previewing Word documents or Quark documents.

[TETENAL]

Originally posted by BuonRotto:
Does the Carbon API offer any sort of plug-in structure like Cocoa apps seem to have avilable to them?

You can have CFBundles (or CFPlugins) and it really doesn't matter whether they are Carbon or Cocoa.

I can see why depending on QT for previews is too limiting, when you can make good use of previews for things like InDesign or Quark layouts, not to mention Word documents.

QuickTime is by no means limited. You can create preview components for any arbitrary file type. There is no need for a "Finder preview plug-in" API when QuickTime is handling this already for all applications fine and well.

[IamBob]

Uh, you don't see third parties fundamentally rewriting bits of applications with InputManagers. The reason that it's broken is because it's a poorly written application, not because it's Carbon or Cocoa

Well, you don't see it but that doesn't mean it can't be done - if the Finder were Cocoa you could inject your code and do *whatever*. The process is well understood, if not well documented (I've never seen the docs or it's been ages and still managed one for Safari).

A third-party can still inject code (via APE) into the Finder and give us preview plugins but the process is not as well understood or built-in so it's less likely to happen or be successful.

the Carbon/Cocoa distinction is meaningless.

How so? It seems to me that the Carbon/Cocoa distinction is the main problem. If it were easier to modify the Finder there wouldn't be a problem - with a Cocoa Finder, instead of this thread there could be one titled, "Can someone write a Finder plugin for .abc?" or, "Can someone write this Finder enhancement?"

That it's Carbon makes it "more broken" since it's not as easily fixed. Get it yet?

[Chuckit]

Originally posted by TETENAL:
You can have CFBundles (or CFPlugins) and it really doesn't matter whether they are Carbon or Cocoa.

Actually, Carbon offers more flexibility when it comes to plugins than Cocoa does. With Cocoa, you can't even unload a plugin once it's been loaded.

[Sven G]

Originally posted by TETENAL:
The Panther Finder is tabbed.

Well, sort of, in the way you described it: but that isn't as intuitive as in Safari, nor was that feature meant to be an implementation of tabs, probably.

[Angus_D]

Originally posted by TETENAL:
You press ⌘T to add a folder and then switch between them in the bar on the left.

Yeah, if you look at the menu option cmd-T is "Add to sidebar". So what you really mean is that the Finder has a sidebar, not that the Finder has tabs. The sidebar behaves differently than tabs do. They are not the same.

[Angus_D]

Originally posted by IamBob:
Well, you don't see it but that doesn't mean it can't be done - if the Finder were Cocoa you could inject your code and do *whatever*. The process is well understood, if not well documented (I've never seen the docs or it's been ages and still managed one for Safari).

A third-party can still inject code (via APE) into the Finder and give us preview plugins but the process is not as well understood or built-in so it's less likely to happen or be successful.

Uh, abusing the Objective-C runtime and Cocoa' InputManager bundles (which are, you know, designed for implementing "input servers" (see http://developer.apple.com/documenta...ger/index.html) to randomly modify the behaviour of applications is wholly unsupported and evil.

How so? It seems to me that the Carbon/Cocoa distinction is the main problem. If it were easier to modify the Finder there wouldn't be a problem - with a Cocoa Finder, instead of this thread there could be one titled, "Can someone write a Finder plugin for .abc?" or, "Can someone write this Finder enhancement?"

That's a totally assbackwards way of considering it. The problem is that the Finder does not provide an API through which developers can extend it in this way, period. If it was Cocoa, they'd still have to make it load plug-in bundles and provide some sort of supported way to do it if they wanted to get any sort of adoption.

You can hack stuff if it's Carbon or Cocoa, that's beside the point. If it's Cocoa it's rpobably easier to hack it about, but that can also be a disadvantage.

That it's Carbon makes it "more broken" since it's not as easily fixed. Get it yet?

For the fix to matter, it has to come from Apple, so whether it's Carbon or Cocoa doesn't matter.

I'm sorry, but you shouldn't rely on InputManagers being able to do what they do, and you certainly shouldn't rely on the internal implementation details of applications which load your "InputManager" (which isn't really an inputmanager at all, it's just an abuse of the poor restrictions placed on the bundle loading code inside Cocoa).

[Millennium]

Originally posted by IamBob:
Well, you don't see it but that doesn't mean it can't be done - if the Finder were Cocoa you could inject your code and do *whatever*. The process is well understood, if not well documented (I've never seen the docs or it's been ages and still managed one for Safari).

This is unlikely to continue working in the future, given that it's a bad hack which will inevitably introduce some security hole or other, and then Apple will close it up. They're not Microsoft, desperately clinging to a security hole because some software out there uses it. They do it right.

How so? It seems to me that the Carbon/Cocoa distinction is the main problem. If it were easier to modify the Finder there wouldn't be a problem...

Indeed, but Cocoa doesn't make it easier to modify except through this hack. What needs to happen is that Apple needs to do this right, by documenting the plugin API which currently exists. That would be true for Carbon or Cocoa.

That it's Carbon makes it "more broken" since it's not as easily fixed. Get it yet?

Hacking a hole in Cocoa doesn't count as a fix.

[TETENAL]

Originally posted by Millennium:
What needs to happen is that Apple needs to do this right, by documenting the plugin API which currently exists.

The API for previews is documented. See my post above.

[Millennium]

Originally posted by TETENAL:
The API for previews is documented. See my post above.

That's also quite hackish, to be honest. QuickTime is not meant for viewing AppleWorks documents, to give one example, so why should it be able to preview them? That will only confuse people who use QuickTime in other contexts, who will assume that since QuickTime can preview a document that it should be able to view those same documents. That's a pretty reasonable assumption, too, given that QuickTime has to be able to at least open a document in order to preview it.

This is why I think that the Finder needs something more generalized than simply latching onto QuickTime's own functionality. It gets the job done, yes, but only by creating inconsistent behavior in QuickTime apps.

[TETENAL]

Originally posted by Millennium:
That's also quite hackish, to be honest.

It's not hackish, it's a well defined API like any other is as well.

QuickTime is not meant for viewing AppleWorks documents, to give one example, so why should it be able to preview them?

Really, whether you would consider Preview Components part of QuickTime or not doesn't really change a dime. Consider it part of Carbon if you are more happy with it. I guess since QuickTime already handles so many media formats (movies, pictures, text, PDF) Apple considered them part of QuickTime, but the only thing that means is where it is drawn into an organizational chart of APIs.

That will only confuse people who use QuickTime in other contexts, who will assume that since QuickTime can preview a document that it should be able to view those same documents. That's a pretty reasonable assumption, too, given that QuickTime has to be able to at least open a document in order to preview it.

This confuses nobody. How many users know that the Finder preview is done by QuickTime? Very very few. I really doubt that users expect to be able to open anything that Finder previews in QuickTime Player. Most people see QuickTime Player as a movie player and are surprised that it can open PDF documents, even though that's previewed in Finder. So people don't build a "preview in Finder means openable in QuickTime Player" assumption.

This is why I think that the Finder needs something more generalized than simply latching onto QuickTime's own functionality. It gets the job done, yes, but only by creating inconsistent behavior in QuickTime apps.

If this were a Finder plug-in API only, then only the Finder could display previews. However since this is a general plug-in API, now any application can generate and view previews. If other applications don't want to do this however, they just don't. No inconsistent behavior is introduced to them.

[IamBob]

I'm sorry, but you shouldn't rely on InputManagers being able to do what they do, and you certainly shouldn't rely on the internal implementation details of applications which load your "InputManager" (which isn't really an inputmanager at all, it's just an abuse of the poor restrictions placed on the bundle loading code inside Cocoa).

It's perfectly reasonable to assume that InputManagers will continue to work the way they do (a serious shift could happen but is not likely and would probably have an advanced warning). And you don't really rely on an application's internal implementation details unless you're sure of what they are - you use sanity checks such as DuckTyping, app version checking, structure testing (mmm, introspection), etc. so that if something changes you know not to load your modifications.

How many people are writing SIMBL (InputManager) plugins that take advantage of the "poor restrictions"? You may perceive it as being evil but I don't mind - as a user I think it's nice getting extra functionality and as a (admittedly, hobbiest) developer it's nice being able to create those extras for my friends and family.

This is unlikely to continue working in the future, given that it's a bad hack which will inevitably introduce some security hole or other, and then Apple will close it up.

I'm not losing any sleep over the potential for malicious InputManagers. You have to be an admin to install them, they're few and far between and any admin worth his salt wouldn't download from anything but the likes of versiontracker where ratings weed out the bad.


Anyway, if Finder were Cocoa *my* problems with the Finder would cease to exist. That you don't want an infinitely and easily extendable Finder makes no sense to me.

[Chuckit]

Originally posted by IamBob:
A third-party can still inject code (via APE) into the Finder and give us preview plugins but the process is not as well understood or built-in so it's less likely to happen or be successful.

I don't see how the way APE works is less clear than the way InputManagers work. They're both taking advantage of known weaknesses in the memory protection scheme to get their own code into another program's space.

Originally posted by IamBob:
It seems to me that the Carbon/Cocoa distinction is the main problem. If it were easier to modify the Finder there wouldn't be a problem - with a Cocoa Finder, instead of this thread there could be one titled, "Can someone write a Finder plugin for .abc?" or, "Can someone write this Finder enhancement?"

You could do that anyway. People are constantly asking for developers to write one program or another. In this case, it wouldn't be a plugin, but that hardly makes a difference.

And the fact that you can't easily hack the Finder to do things it wasn't meant to do surely isn't Apple's problem. Quite frankly, if you're going to be hacking into other applications, I'd hope you have the skills to use APE.

[Millennium]

Originally posted by IamBob:
It's perfectly reasonable to assume that InputManagers will continue to work the way they do (a serious shift could happen but is not likely and would probably have an advanced warning).

Yes, but the fact remains that they're exploiting what is essentially a bug in the design of InputManagers, and bugs are subject to being fixed.

[Angus_D]

Originally posted by IamBob:
It's perfectly reasonable to assume that InputManagers will continue to work the way they do

It's only reasonable to expect behaviour to continue as documented. You are relying on (and flagrantly abusing) an undocumented implementation detail.

[IamBob]

I don't see how the way APE works is less clear than the way InputManagers work. They're both taking advantage of known weaknesses in the memory protection scheme to get their own code into another program's space.

InputManagers (IMs*) are just ObjC plugins being loaded into ObjC apps - no foolery involved, this is built-in and their main use is documented.

Quite frankly, if you're going to be hacking into other applications, I'd hope you have the skills to use APE.

Developer skill has little to do with it, the crap gets weeded out anyway. Besides, a lot of people won't touch APEs but don't mind IMs...go figure. Setting aside the investment APEs require from their developers (license, time, whatever).


To really understand, lets all read CocoaInsecurity....or pretend to, anyway.

Yes, but the fact remains that they're exploiting what is essentially a bug in the design of InputManagers, and bugs are subject to being fixed.

Individual apps could discourage "abusive" IMs as detailed in the article above but I wouldn't expect a general "fix" anytime soon.

It's only reasonable to expect behaviour to continue as documented. You are relying on (and flagrantly abusing) an undocumented implementation detail.

Maybe Apple isn't pointing it out directly (I'm not about to go sifting) but what you can do with plugins in ObjC apps is known, no matter how they're loaded.

As a commercial/shareware developer, that you can abuse IMs could be kind of irritating. Since I'm just a user, I don't mind at all. Though, I've been thinking about writing some shareware lately so it's really not so black and white but I think the good they can bring far outweighs any bad.

[Chuckit]

Originally posted by IamBob:
InputManagers (IMs*) are just ObjC plugins being loaded into ObjC apps - no foolery involved, this is built-in and their main use is documented.

Yes, their main use is to provide input services. They were never intended to mess with the program they're being loaded into. The foolery comes in using plugins designated for a particular purpose and twisting them to be used to another purpose. It's "foolery" just as much as APE using debugger hooks to invade another program's memory space.

[Angus_D]

Seriously, why do people that aren't developers consider themselves qualified to pass judgement on whether one API is "better" than the other and make sweeping statements about how the OS works?

[IamBob]

It's "foolery" just as much as APE using debugger hooks to invade another program's memory space.

You asked how APEs were less clear than IMs. I was talking specifically about developing them and how they get loaded, no foolery there. What they do in the host doesn't change that point - IMs are loaded by the system and the entry point is documented, APEs invade.

Abusing the system is another matter but it's still not black and white, no matter which side you tend to take.

[Angus_D]

Originally posted by IamBob:
You asked how APEs were less clear than IMs. I was talking specifically about developing them and how they get loaded, no foolery there. What they do in the host doesn't change that point - IMs are loaded by the system and the entry point is documented, APEs invade.

"Loaded by the system"? So do kernel extensions. Doing this from a kext would be horrendous disgusting thing to do, are you advocating that?

[Chuckit]

Originally posted by IamBob:
You asked how APEs were less clear than IMs. I was talking specifically about developing them and how they get loaded, no foolery there. What they do in the host doesn't change that point - IMs are loaded by the system and the entry point is documented, APEs invade.

They both invade. A program doesn't specifically ask for InputManagers any more than it asks for APEs. Just because the system loads bogus InputManagers, that doesn't mean they're any less invasive than APE. They're both just ways of getting your code into another program's memory space, and both are provided by Apple (for different purposes).

[IamBob]

Happy New Year!

"Loaded by the system"? So do kernel extensions. Doing this from a kext would be horrendous disgusting thing to do, are you advocating that?

I know you're not trying to put words in my mouth but why would you think..no, no...

IMs are at the application level. Much cleaner that way, should something go sour you can remove the IM and relaunch the affected app.

I don't even want to think about how bad you could whack things if you did it with a kext. No, that's obviously the wrong place for doing something that we've already got, cleanly I might add, with IMs.

I know I don't need a "Duh!" in there but man were my fingers twitching to type it.

They both invade. A program doesn't specifically ask for InputManagers any more than it asks for APEs. Just because the system loads bogus InputManagers, that doesn't mean they're any less invasive than APE. They're both just ways of getting your code into another program's memory space, and both are provided by Apple (for different purposes).

You're right, apps (or their developers) don't usually ask for IM or APE plugins. When the interface is "abused" (by the plugin, for the user) in that case, I suppose they can be pretty invasive. But I'd argue that people get invasive surgery all the time and live to tell the tale (or don't!) - why should apps be much different, especially when it's pretty straight forward and the tools and documentation are *right* there? Not like you're going to hurt anything by taking out an app's kidney (or adding another liver, heh) - at worst it crashes, you remove the IM and shock the app back to life - no biggy.

Lets say you know FooCorp is never going to add SomeSpiffyFeature that saves you 3 seconds a run (w/ n runs a day, that could add up quick) and makes you smile. Why can't you add it with a plugin? Afterall, it is your computer....just another tool. That it can bend so easily to your will is a huge advantage, I'd say...score one for OSX.

<much scratching of head>

Whatever, people will do what they do with their tools, one way or another. Sorry I even mentioned them in the first place. evil and invasive, maybe..but when they're useful...

[Angus_D]

Originally posted by IamBob:
Whatever, people will do what they do with their tools, one way or another. Sorry I even mentioned them in the first place. evil and invasive, maybe..but when they're useful...

But they're no substitute for a defined, supported API.

[Chuckit]

Originally posted by IamBob:
You're right, apps (or their developers) don't usually ask for IM or APE plugins. When the interface is "abused" (by the plugin, for the user) in that case, I suppose they can be pretty invasive. But I'd argue that people get invasive surgery all the time and live to tell the tale (or don't!) - why should apps be much different, especially when it's pretty straight forward and the tools and documentation are *right* there? Not like you're going to hurt anything by taking out an app's kidney (or adding another liver, heh) - at worst it crashes, you remove the IM and shock the app back to life - no biggy

I was arguing against the idea that using InputManagers to hack an application is somehow "clean" while APE using debugger hooks is somehow "dirty." They're essentially two means to the same end. That's what I was saying.