Uh oh InputManager is kaput in Leopard. Plugins be damned
http://arstechnica.com/journals/appl...or-gold-master
I've been enjoying some of the plugins in Safari and AddressBook via InputManager. Now that this is going bye-bye it seems that Apple better have some way of offering plug-in support or Leopard will deliver Safari/Mail/AB versions that may have "less" support for many consumers than what they have today.
Quote:
One more tip we got regarding Leopard, is that InputManager plugins are no longer allowed. That's right... no more "haxies" from anybody besides Apple. No more Apple menu hacks. No more Safari plugins. InputManager is not exactly the same as APE, but the two work together to load plugins based on which app is being launched at the time. "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.
One more tip we got regarding Leopard, is that InputManager plugins are no longer allowed. That's right... no more "haxies" from anybody besides Apple. No more Apple menu hacks. No more Safari plugins. InputManager is not exactly the same as APE, but the two work together to load plugins based on which app is being launched at the time. "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've been enjoying some of the plugins in Safari and AddressBook via InputManager. Now that this is going bye-bye it seems that Apple better have some way of offering plug-in support or Leopard will deliver Safari/Mail/AB versions that may have "less" support for many consumers than what they have today.
Comments
They just want control over their OS. Not to mention a much more pure OS. Imagine from a support side how tough it would be to diagnose a problem over the phone if all these little haxies have deamons running around messing with the system
Yes I understand their quandry. I'd love to see them announce a plugin specification that works across many of their applications but protects the user from malicious use.
Firefox is an "ok" browser until you see the plethora of plugins that are available. Apple can and should foster an environment like this for Safari/Mail/AB IMO through plugins.
Just what are they building over there in Cupertino?
For the record, I don't care if Leopard is released in May, June or September.
Apple should take the time and get it right.
But holding businesses hostage for their PR surprises is another matter. Surely by now they could have hosted a PR event to let us know what the final features are and when it is expected on the market.
Content Creation companies are juggling new Mac Pro purchases, the CS3 launch as well as company budgeting schedules. Keeping pros in the dark so that Jobs can pull a rabbit out of a hat is now a counter-intuitive strategy.
If we get system wide Python/Ruby application scripting, you can load custom modules or whatever and it could open up the modding to a whole new level. Python and Ruby are much more powerful than Applescript. That's not to say that setup won't have limitations of course but I can't say I'd really miss any input managers
If there's no way to "intercept" content and then "reinject" it back into the stream, this will have no consequence in the context of a Safari or Address Book plugin/extension.
Plugins are not afterthoughts... unofficial InputManager hacks are an afterthought.
A plugin is an add-on. It is adding/modifying/changing functionality to an existing app, the plugin is usually done by someone else other than the original creator of the app. It's sloppy, very sloppy. The right way is to incorporate it into the app without the need for a plugin, hence taking all aspects of design into consideration. That's the right way. I don't care if the plugin is official or unofficial, it's still sloppy.
I would speculate on IB 3.0 when you test it yourself.
Interface Builder 3.0 is brand new for Leopard. The new version provides even better integration with Xcode, a library window for access to all your controls, a new connections interface, support for Leopard's new visual effects, and the new XIB file format. Learn how to put all these new features to use, and see a demo that creates a great new user interface from scratch, right in front of your eyes.
So the NIB format has changed to XIB.
Interface Builder 3.0 provides a brand-new plugin architecture for developers to integrate their custom controls directly into the new Library window. Learn how to build your custom control as a plugin, how to give your control a unique look, and even how to create its own specialized inspector.
A plugin is an add-on. It is adding/modifying/changing functionality to an existing app, the plugin is usually done by someone else other than the original creator of the app.
Ok.
It's sloppy, very sloppy. The right way is to incorporate it into the app without the need for a plugin, hence taking all aspects of design into consideration. That's the right way. I don't care if the plugin is official or unofficial, it's still sloppy.
How do you explain Photoshop plugins? You figure all that functionality should be put in PS by Adobe?
Your idea of plugins is a tad skewed.
If we take iPeon's reasoning a bit further, 3rd party applications do not take the whole system into account and therefore 3rd party software should be banned as well. Especially software such as Parallels that install kernel extensions. After all, the MOAB clearly showed us that 3rd party software such as VLC can open the system up to new vulnerabilities.
Ok.
How do you explain Photoshop plugins? You figure all that functionality should be put in PS by Adobe?
Your idea of plugins is a tad skewed.
Plugins are a common sense way of extending applications. There are a million and one good examples. iPeon's comments are totally without merit.
...especially Inquisitor.
Seconded.
A plugin is an add-on. It is adding/modifying/changing functionality to an existing app, the plugin is usually done by someone else other than the original creator of the app. It's sloppy, very sloppy. The right way is to incorporate it into the app without the need for a plugin, hence taking all aspects of design into consideration. That's the right way. I don't care if the plugin is official or unofficial, it's still sloppy.
The right way is to have an exposed Plugin API that leaves room for third parties to extend functionality of an application. The sandbox with which they play in this should be so that these plugins don't break the stability of the parent application.
The right way is to have an exposed Plugin API that leaves room for third parties to extend functionality of an application. The sandbox with which they play in this should be so that these plugins don't break the stability of the parent application.
Plug-ins are important for every platform. InputManager plugins are plentiful and useful. Apple is going to have to enable an architecture that is safe but allows most of these plugins to survive. If not Leopard will be a step back in usability for many users.
Plug-ins are important for every platform. InputManager plugins are plentiful and useful. Apple is going to have to enable an architecture that is safe but allows most of these plugins to survive. If not Leopard will be a step back in usability for many users.
Either they don't check out the SVN branch of WebKit or they don't like the Plugin architecture that is in the latest SVN branch.
I hope Safari will remember which windows were open when it crashed or you quit it, and restores them on relaunch. That's the only reason I purchased Saft. Whenever Saft is broken by a system update, I miss this feature. I guess I will have to switch to OmniWeb, which I own, but prefer not to use because of its own problems.
OmniWeb is built around WebKit.
Either people don't build WebKit and see the Plugins API or they are getting the gospel from a third party that they are left out in the cold.
http://trac.webkit.org/projects/webk...WebKit/Plugins
The Text system is being replaced with Core Text, as is well known.
It stands to reason a replacement is in store.
http://developer.apple.com/wwdc/sessions/
Receive one-on-one technical assistance and troubleshooting advice from the Core Text engineering team. Learn how to use the advanced font handling and blazingly fast Unicode layout capabilities of Core Text. Bring your laptop, your code, and your questions.
When we see Core Text I look forward to everyone praising the replacement to NSInputManager and how they've changed the entire InputServer/InputClient system of NSInputManager.
Speculation is one matter. Complaining about abandonment is overblown.
Leopard supports combining the power of the desktop experience with the latest advanced Web 2.0 techniques in hybrid-Web/Cocoa applications. Discover advanced uses of WebKit, XHTML, CSS, and AJAX in creating rich user interfaces for applications. Learn how industry experts are building lightweight Cocoa applications that allow easy binding of JavaScript to CoreData, and hear how they intend to use this configuration to make powerful applications.