After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 494416 - plugins should have configure widgets within plugin-manager and stop abusing preferences
plugins should have configure widgets within plugin-manager and stop abusing ...
Status: RESOLVED WONTFIX
Product: evolution
Classification: Applications
Component: Plugins
2.22.x (obsolete)
Other All
: Normal minor
: ---
Assigned To: evolution-plugin-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2007-11-07 01:31 UTC by Sam Morris
Modified: 2012-08-12 13:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Sam Morris 2007-11-07 01:31:12 UTC
Plugins such as 'prefer plain text' or 'calendar publishing', once enabled, don't appear to actually do anything. It took quite some time for me to discover that I actually need to go to my preferences to configure them... even though the plugin window has a 'Configure' button (that does nothing).

Other information:
It might make sense for certain plugins to not actually be treated as plugins in the user interface; that is, make it impossible to disable them, and even hide them in the plugin list.

I believe Rhythmbox does this for parts of its functionality that are implemented using its plugin mechanism, but that don't make sense to disable.
Comment 1 Gilles Dartiguelongue 2007-11-11 19:35:19 UTC
This is currently no flexible way of doing this in evolution. It would first require that all plugins have an entry in gconf.
Comment 2 Sankar P 2008-03-19 05:48:43 UTC
This is a bug. We need to make all plugins configure data move to plugin-manager. It is a pending task for a while now.  Also, MBarnes is doing some work to make the plugins descriptions more user-friendly. 
Comment 3 Matthew Barnes 2008-03-19 10:05:49 UTC
Speaking of GConf, if the migration aspect of this isn't too painful, it would be nice if we could standardize where plugin settings are kept in GConf:

   /apps/evolution/eplugin/<plugin-name>

Currently plugin settings are scattered all about the GConf tree.  Maybe this could be supported in the plugin framework somehow, so that plugins don't have to decide for themselves where to put their settings.
Comment 4 Sankar P 2008-03-19 11:11:48 UTC
Problem is some of the old plugins tried to seamlessly integrate with evolution and hence used the common gconf directories. For new plugins, we should restrict to :

/apps/evolution/eplugin/<plugin-name>

For backward compatibility reasons, I may suggest to leave old gconf dirs. as they are.
Comment 5 Matthew Barnes 2008-03-19 11:16:16 UTC
I'm fine with that.  Some of them don't look too painful to migrate, but maybe we can handle them on a case-by-case basis over time.
Comment 6 André Klapper 2012-06-26 16:52:53 UTC
It is already the case that there are "Configure widgets".
Not sure how many plugins use that though.
It feels like a huge mess.
Comment 7 Matthew Barnes 2012-08-12 13:39:37 UTC
Closing this as WONTFIX since I now believe the opposite.

EPlugin is deprecated, the Plugin Manager window will be going away as soon as possible, and any configuration UI for these modules should be dispersed to an appropriate context -- whether that be in Preferences, the Account Editor, or integrated into the main UI.