GNOME Bugzilla – Bug 577462
[bbdb] Pidgin sync plugin unfindable in the UI
Last modified: 2014-11-28 13:30:32 UTC
Running 2.24.5 I wanted to disable the buggy bbdb plugin that causes huge annoyance - see https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/222396 . But it's not listed in Edit>Plugins. Instead I have to go to Edit>Preferences>Mail Preferences (sic!)>Automatic Contacts. Probably same for Auto-contacts. Other plugins are listed and even have a configure button. I dislike wasting ages for finding out where you've hidden setting foo.
Also, nobody wants Pidgin. What about Empathy that is part of GNOME?
I thought the complaint was we show too -many- plugins in Edit->Plugins. It's probably marked as a system plugin now. System plugins are plugins that implement some "core functionality" and are not designed to be disabled, so we don't show them in the plugin list (it's a cheap hack, I realize). You may notice several other "core functionality" plugins missing like "Local Address Books" and "Local Calendars". It's possible BBDB was mislabeled. Need to check this.
I know about the system plugins. :) But this is nothing core... It's a buggy and not really useful plugin that makes Pidgin come up with 4 useless popups everytime I start it according to the Launchpad report.
(In reply to comment #3) > I know about the system plugins. :) It's not a system plugin, and it never was (according to git). Its name is "Automatic Contacts" and I see it in Edit->Plugins. That's true the configuration is not in Edit->plugins. Maybe some (or the best all?) plugins should have its configuration in preferences and on a Configure tag in Plugins? It's slightly against bug about "too many option in Edit->Preferences from plugins", but on the other hand, if a user is searching for options, he's not going to look in Edit->plugins, but it Edit->Preferences. > But this is nothing core... It's a buggy and not really useful plugin that > makes Pidgin come up with 4 useless popups everytime I start it according to > the Launchpad report. Believe or not, it's unrelated to evolution's plugin, because it's a one way plugin, from pidgin to evolution, and evolution is only reading a buddy list file, it's not writing there. (In reply to comment #1) > Also, nobody wants Pidgin. What about Empathy that is part of GNOME? Empathy, Empathy... I like pidgin. And I know there is a bug report about supporting Empathy too. I noticed it, but... ah, yeah, quite new bug report, see bug #590898. So what here? Any idea or suggestions?
This is more of a general "what to do with all these damn plugins" comment: Milan makes an excellent point about users looking for options in Preferences. It doesn't occur to them to look in the Plugin Manager, nor should it. I also have to wonder how many users really go through and pick and choose plugins to enable. We ship with all plugins enabled by default anyway, and I bet the vast majority of users leave it that way. Or don't even know you -can- pick and choose. As I've been thinking about this whole plugin issue for several years now, I'm starting to come to the conclusion that the Plugin Manager and the whole concept of disabling plugins needs to die. I honestly doubt very many users would notice. And it would force us to -think- about where and how settings should be integrated with the rest of the app. They don't necessarily have to be in the Preferences window either. In fact, the Preferences window should be regarded as a last resort. Take the "Custom Header" and "Face" plugins, for example. There's no reason why those configuration settings couldn't be integrated directly into the composer window. Inserting a custom header should just add a row to the list of existing headers in the composer, and if your message is going to a face header the composer should show a preview with buttons to remove it, change it, or hide the preview to free up space. Furthermore half of our plugins (including the system plugins) don't even need to use the EPlugin framework, really. Anything whose purpose is to handle information or communication of a certain type (MIME type, server type, etc.) would be better off subclassing an extension point class and loading itself from our new 'modules' directory as a GTypeModule. Apologies for the rambling. Just trying to get my thoughts written down somewhere. At some point, when I'm more sure of myself, I'll post a more coherent writeup to the hackers list.
Maybe use bug #494416 for configuration widgets movement and other stuff you mentioned above. What about marking this one as a duplicate? But honestly, this one is an example of a plugin which should have its options in Preferences. Where else? Also, I disagree of hiding plugin manager, the core plugins are core plugins, but the rest should be visible somewhere. Maybe not many, but there still are external plugins available (I know of one, at least) :)
Hm. Interesting discussion. I'm reopening because I don't see any open non-developer question.
This had been done recently. *** This bug has been marked as a duplicate of bug 739585 ***