Adium

Ticket #1005 (new defect)

Opened 3 years ago

Last modified 7 months ago

"Disable plugin" dialog strongly discourages use of external plugins

Reported by: catfish_man Assigned to:
Priority: normal Milestone: Adium 1.4
Component: Adium UI Version: 1.0svn
Severity: normal Keywords:
Cc: Patch: None
Pending: 0

Description

Either we shouldn't allow external plugins (like Myko), or we should be a little friendlier towards them.

Change History

07/24/2005 06:55:51 PM changed by evan.s@dreskin.net

Wholeheartedly agree. I think the Proper solution would involve some sort of AdiumXtras advanced preferences pane with a section for external plugins... along with some versioning system for .AdiumPlugin bundles which would let us automatically disable plugins built for old versions of Adium. Thoughts?

07/24/2005 09:31:25 PM changed by catfish_man

References #714

I guess the AdiumXtras prefpane would be a pretty classic master-detail interface, with a list of xtras, and then a view showing information about the selected xtra. Disabled Xtras (ones designed for earlier versions of Adium) could be greyed out and have an "enable" button with a warning that it might not function correctly. Having an "update" and possibly an "update all" button would be nice as well, although it would require website-side support for querying the most recent versions of xtras as well as #73.

07/30/2005 12:21:23 AM changed by adamiser

Plugins have the potential to break with every upgrade. The current system reminds users that they're using plugins which may break with every upgrade. What's the problem?

If you provide a way to disable the notifications, users will forget they're using plugins, the plugins will break with an upgrade, and people will blame it on Adium. If you implement a versioning scheme you're just complication the solution, plugins will still break and users still need to be warned. If you provide in-app updating and downloading of plugins you're over-complicating the application. If the functionality is that important, bundle it. If it's not, then the few users making use of the plugin can deal with a simple and important reminder each time they upgrade.

I've yet to see a proposal to "fix" this that is actually an improvement.

07/30/2005 02:56:42 AM changed by boredzo

hopefully we should have a stable enough API for 0.90 that plug-ins will be unlikely to break with an upgrade. I can't think of any good way to implement a versioning scheme (other than the normal one for libraries, but that would suck if an API changed that the plug-in wasn't using, and the plug-in was rejected because of the change). so I suggest we have a way for a plug-in to run a standardised panel like the following:

The plug-in "MykoGames" is incompatible with this version of Adium, and will be disabled. You may be able to obtain an update from the maintainers' website.
[Go to MykoGames website] [OK]

the plug-in would pass itself, and Adium would fetch the name and URL from the plug-in. (one way I can see implementing this: -[AICorePluginLoader warnForIncompatiblePluginVersion:(AIPlugin *)plugin])

currently, we present a warning when (and these are just my observations; I could be wrong about the criteria):

  • the plug-in's modification date changes
  • Adium's modification date changes
  • the plug-in has not been seen before (or it has been removed, causing Adium to forget about it)

in other words, the mere act of installing a plug-in causes a warning, even though data is probably not at risk. (if it was at risk, the plug-in would probably know this better than Adium would.) and updating Adium can cause multiple warnings, one for every plug-in.

this is far too zealous, definitely hostile to plug-ins, and a hassle whenever a user installs a plug-in (which should be considered a normal part of using Adium). I say the panel's wording and default button should change, and the panel should be run less often (probably whenever the plug-in tells it to).

08/27/2005 02:08:46 PM changed by adamiser

  • status changed from new to closed.
  • resolution set to wontfix.

I like being hostile towards plugins. Installing plugins is not a normal part of using Adium. :)

08/27/2005 04:19:26 PM changed by catfish_man

  • status changed from closed to reopened.
  • resolution deleted.

Either external plugins shouldn't be supported at all (in which case Myko will just switch to using a tiny internal integration plugin and have the main program be a chatkit app), or they should be supported correctly. The current behavior of "you can do it, but we don't want you to" is broken.

08/27/2005 04:57:27 PM changed by adamiser

If supporting them "correctly" involves an advanced preference pane, a master-detail interface, website-side support, multiple warning panels, #714, and #73 then I'll be siding with "not supported at all". Do you realize how much work and complication you're describing here for the benefit of such a small portion of our users?

Piling up an impossible workload of trac tickets does not benefit Adium. Set the goals to something reasonable and then we'll talk.

I'd be willing to go along with boredzo and make two minor changes:

  1. Allow plugins to specify a 'safe' version for which they've been tested to avoid a warning on initial install.
  2. Present a single warning dialog even if multiple out of date plugins are installed.

08/27/2005 06:14:08 PM changed by Catfish_Man

Sounds good to me. I'm also fine with the "don't support them at all" policy. As far as I know, there are only two external plugins, and neither one is used often.

09/20/2005 05:41:19 AM changed by Cortland Klein <me@pixelcort.com>

Plugins should have a build number of a known compatible Adium (the most recent build the plugin's dev team has certified compatibility with). Plugins should also have a URL where a user could potentially find newer versions of the Plugin.

If Adium sees that the compatibility build number in the Plugin is lower than the build number of itself, it will prevent the plugin from functioning and provide the user with the URL found in the plugin. If the plugin has no build number, Adium should disable the plugin and inform the user that the Plugin is not compatible with itself.

Rationale: Simpler implementation in Adium (check buildnumber, disable plugin, provide Alert with URL). Simple implementation in Plugins (buildnumber + URL). User friendly. Less Plugin hostile.

09/20/2005 05:45:15 AM changed by boredzo

pixelcort: so every time Adium gets updated, all plug-ins should immediately cease to work, whether they could work or not?

no. it should be up to the plug-in to know whether it can work or not.

12/07/2005 06:21:30 PM changed by tick

  • owner changed from nobody to Catfish_Man.
  • status changed from reopened to new.
  • field_haspatch changed.

This in general all sucks, but supporting plugins is better than not supporting them.

The major problem is that users tend to associate crashes caused by plugins with Adium itself, when it could very well be Adium by itself, or the plugin.

Here is my thought on it: Prompt when installing, do whatever there.

When Adium crashes, we should look at what plugins were installed, and report those as well in the crash report. We should also list them in the crash reporter, and offer to disable the plugins to see if that resolves the issue.

I'm assigning to Catfish_Man to see if he has any other ideas on this one.

01/03/2006 04:39:56 PM changed by evands

  • milestone changed from Adium X 1.0 to Sometime after 1.0.

This should be fixed. I don't think it's a requirement for 1.0, however.

04/26/2006 10:48:53 PM changed by tick

  • milestone changed from Sometime after 1.0 to Adium X 1.1.

I don't think this should be required in 1.1, but it needs to be revisited

09/17/2006 07:23:40 PM changed by tick

  • milestone changed from Adium X 1.1 to Needs dev review.

11/25/2006 11:37:52 PM changed by boredzo

We should include a list of all installed plug-ins in the crash report sent by the Burning Duck.

07/03/2007 07:23:03 PM changed by evands

  • patch_status set to None.
  • pending changed.
  • milestone changed from Needs dev review to Adium X 1.2.

Let's plan on improvements in this area for 1.2 if possible.

09/16/2007 10:04:19 PM changed by tick

I'd like to address this in 1.3 or 1.4 actually. Reason being is that we have enough on our plates with the mass amount of stuff for the SoC stuff.

What does everyone else think?

10/04/2007 12:52:39 PM changed by zacw

Perhaps after confirming a plugin once, Adium should only ask on the next version++?

10/07/2007 06:36:10 PM changed by evands

  • milestone changed from Adium X 1.2 to Adium X 1.3.

First, agree with Chris. Shifting to 1.3.

10/07/2007 06:47:13 PM changed by evands

(In [21239]) Only confirm loading of a plugin if the version of Adium is greater than the last confirmed version. Exposed the AIAdium method compareVersion:toVersion: for this purpose. Refs #1005

05/03/2008 04:34:57 PM changed by Catfish_Man

  • owner deleted.

I'm not particularly interested in this anymore, tbh. Unassigning.

05/15/2008 08:37:59 AM changed by djmori

05/21/2008 02:36:23 AM changed by Catfish_Man

  • milestone changed from Adium X 1.3 to Adium X 1.4.