GNOME Bugzilla – Bug 496839
Plugins unusability UI and logic
Last modified: 2012-06-16 22:48:03 UTC
Hello, The way plugins are handled in evolution is horrible from the user point of view. Evolution comes with more than 40 plugins (!!!). Please look at the screenshot I have attached. This is really too much. Plugins are programmatically convenient for developper to separate core functions from feature; but I don't think it worth to present all them to user. I think some plugins should not be displayed and should be activated by default; because I don't the point not having HTTP Calendar, or IMAP features; another set of plugins that could be activated by default and not show are the plugins which require zero config, like the face. Globally, I think the plugins infrastructure should be smart, and doesn't action from the user (like activating the IMAP feature when the user has a IMAP account,or the bogofilter plugins when it has bogofilter) Another problem is the way the plugins are presented; I think it require some rework.
Created attachment 99107 [details] Plugin UI capture Do you think this is really appealing ?
+1.
I think we've made /some/ progress on the presentation of plugins in 2.21 via the Banshee-style tabbed notebook [1]. But I agree with your larger point and I think it requires a change in attitude among developers as much as a change in code. I think too often our plugin system is used as a way to just pile on someone's pet feature without careful thought about how it should integrate with the rest of the application, with the excuse of "well if you don't like it just turn off the plugin." I find it especially egregious when core developers submit plugins for frequently requested features instead of integrating the feature properly into the UI. Having a plugin system and doing it right requires striking a delicate balance between fostering a healthy community of contributors coming up with their own creative hacks for the application and maintaining some measure of quality control about what gets accepted into the core application. The Firefox community does this right, or at least better than us. Three things I think we can learn from them: 1) We ship too many plugins with the core application. They should really be split into their own repository so users have more control over what extra features get installed. I think GNOME in general really needs something akin to http://addons.mozilla.org/, or some maybe some kind of PluginBuddy (cf. CodecBuddy) to support plugin-enabled apps. 2) We enable ALL plugins by default. Even new ones. Hypothetically, if some new plugin were to come along that changes the behavior of the application in some subtle but disruptive way, users must go out of their way to reset the app to the old behavior. And they would be correct to file bugs about it. 3) Way too much core functionality is wrapped up in plugins. Calendar Publishing. Exchange Operations. Groupwise Account Setup. Local Address Books. Local Calendars. Mail Notification. etc. These are not optional features for any modern PIM app, especially if you're some poor corporate user that's stuck relying your company's proprietary email server. To drive the point home, I challenge anyone who relies heavily on Evolution for day-to-day communication and productivity management to try using it for a week with NO plugins. I've tried; it's not fun. I don't have some grand solution. It's a controversial issue and these are just my thoughts on it. People have already gone round and round on this topic on desktop-devel-list. But it seems to me a basic rule of thumb about plugins is that there must be a /compelling/ reason why a user would /not/ want a certain feature for it to make sense as a plugin. Otherwise it should be thoughtfully integrated into the core application, imposing as few extra buttons and knobs as possible. I don't know. We'll see where this goes. [1] http://banshee-project.org/Image:0_11_0_plugins.png
Bumping version to a stable release.
I am taking up this to hide some core plugins to never show in plugin-manager. And one prominent reason why most of the core features are implemented as plugins is because they are easy to write as plugins :)
http://svn.gnome.org/viewvc/evolution?view=revision&revision=35217 http://svn.gnome.org/viewvc/evolution?view=revision&revision=35216 Patch committed. You can use : system_plugin="yes" in the eplug.xml file The main issue however is we need to identify which plugins belong to that category. Now it will be an interesting ;) time to identify the plugins that belong to this category. I believe itip-formatter should belong to this.
Also: Exchange Operations (or any plugin that accompanies an extension package like evolution-exchange, evolution-zimbra, etc.) Local Address Books Local Calendars Startup Wizard I seem to recall andre and/or guenther having some strong opinions about this.
Probably when changing plugins itself, change also the enable callback to not able to disable the plugin, because otherwise there is no way (at the moment) to enable/disable system plugin, and it sometimes happen to disable it by an accident. I was looking to: http://svn.gnome.org/viewvc/evolution/trunk/e-util/e-plugin.c?r1=35216&r2=35215&pathrev=35216 There is a bug or I miss something, you said system_plugin="yes", but you compare to "true" and further more, you *set* flag for all but "true", thus all plugins with this attribute other than "true" are considered as system. Do I see that right?
(In reply to comment #8) > Probably when changing plugins itself, change also the enable callback to not > able to disable the plugin, because otherwise there is no way (at the moment) > to enable/disable system plugin, and it sometimes happen to disable it by an > accident. Yeah good point. Especially for Exchange Operations. That one /still/ likes to disable itself on me from time to time and I have no idea why.
CalDAV should also be a system plugin, I can patched that in, since without that plugin you totally loose CalDAV functionality.
> I was looking to: > http://svn.gnome.org/viewvc/evolution/trunk/e-util/e-plugin.c?r1=35216&r2=35215&pathrev=35216 > > There is a bug or I miss something, you said system_plugin="yes", but you > compare to "true" and further more, you *set* flag for all but "true", thus all > plugins with this attribute other than "true" are considered as system. Do I > see that right? > Fixed.
(In reply to comment #9) > (In reply to comment #8) > > Probably when changing plugins itself, change also the enable callback to not > > able to disable the plugin, because otherwise there is no way (at the moment) > > to enable/disable system plugin, and it sometimes happen to disable it by an > > accident. > > Yeah good point. Especially for Exchange Operations. That one /still/ likes > to disable itself on me from time to time and I have no idea why. > I was wondering if I can make all system plugins always enabled by default on launch of Evolution. But some people really do not want system plugins ;) Like, one who uses mailer alone, will not want itip-formatter or Caldav etc. However, IONSHO they are core and system plugins. So I added a environment variable which will display all plugins (except plugin-manager) EVO_SHOW_ALLPLUGINS. People have to satisfy with that for the time-being until we come up with a better solution :(
http://www.go-evolution.org/CoreEPlugins
Please provide your views or comments in the above wiki. It is a little easier to track the final list in a wiki than in bugzilla.
(In reply to comment #11) > > Fixed. > Thanks, confirming, this is fixed now (revision 35225). Just a note, use system_plugin="true" not ="yes" as described in comment #6.
crevette, can we close this nowadays after hiding lots of stuff by using system_plugin="true"?
I still have 37 plugins in my list. But maybe the version shipping with Hardy doesn't come with system_plugin="true"?
Hardy? That's ages, it's five months ago! :-P
Yes. But the last activity on this bug was also ages ago. :)
Closing this as OBSOLETE since EPlugin is deprecated and we're gradually converting the remaining EPlugins to the newer extension framework. The newer extension framework completely solves the user presentation issue by not presenting them to the user at all.