GNOME Bugzilla – Bug 380636
Configurable plugins
Last modified: 2008-02-27 01:30:50 UTC
While most of the existing plugins do not need configuration by the end user, it would be nice to allow plugins some screen real-estate in the Preferences Dialog. I'll attach a patch that is a start on this. It would be nice to figure out a way to allow the user to easily (with a checkbox) enable/disable plugins as well.
Created attachment 77375 [details] [review] Patch that adds a "Plugins" tab in the Preferences Dialog.
Created attachment 77376 [details] Plugins tab shows list of plugins
Created attachment 77377 [details] Plugin configuration page (unimplemented)
Created attachment 77378 [details] Plugin details
Created attachment 77386 [details] Alternate preferences mockup.
Created attachment 77387 [details] Alternate alternate prefs mockup.
Created attachment 77414 [details] Plugin page for configurable plugin
Created attachment 77415 [details] Plugin page for legacy plugin
Created attachment 77416 [details] Preferences dialog for configurable plugin
Created attachment 77417 [details] [review] Updated patch implementing the new GUI and introducing generics for the plugin manager
Created attachment 77424 [details] [review] Updated patch - Initialize cell renderers from the Plugin stored - Allow toggling plugin state (still needs some action in plugin manager) - Sort plugin list by name
Created attachment 77449 [details] [review] Next incarnation of the patch. - text-views are used for plugin details to support wrapping - new IPlugin properties express which other plugins are required/suggested
Created attachment 77450 [details] Updated plugin details
This is looking really good! I wonder though if we're showing too much information. Can we get by without showing the "Requires" and "Suggests" to the end-user? At least until they actually enable/disable a plugin? Maybe that's fine. Keep up the good work. Have you looked into actually disabling plugins yet?
(In reply to comment #14) > This is looking really good! > > I wonder though if we're showing too much information. Can we get by without > showing the "Requires" and "Suggests" to the end-user? At least until they > actually enable/disable a plugin? Maybe that's fine. Will look at this after implementing enabling/disabling. > Have you looked into actually disabling plugins yet? That's the next thing to do. Could turn out to be much easier than thought, as PluginManager implements similiar functionality in OnPluginCreated and OnPluginDeleted. Could just be a matter of refactoring. When being there, I also could look, why Plugin reloading doesn't work in Tomboy. Guess it has to do with this http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx. And guess to deal with that, each plugin assembly would have to be loaded into it's private AppDomain, which can be unloaded later on. Well, but I will not be able to look into this before monday.
Created attachment 77730 [details] The leaking references warning
Created attachment 77731 [details] [review] Yet another version of the patch This version of the patch uses Attributes instead of virtual methods for describing plugins and it provides enabling/disabling of plugins. When disabling fails due leaking references (usually event handlers) and if DEBUG is defined a warning is shown. Don't know if this leak detection should be always enabled (see Attachement #77730).
Created attachment 77765 [details] [review] Nearly final incarnations Plugin state is stored in GConf. Leak detector is activated by some command line option. Guess makes sense to test and commit now. After that the default plugins have to be verified with the leak detector and fixed.
Just applied your patch onto my working copy and got the following when attempting to disable the PrintPlugin (haven't looked at why yet): Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at Tomboy.PluginManager.DetachPlugin (System.Type type) [0x0004d] in /home/boyd/projects/tomboy/Tomboy/PluginManager.cs:505 at Tomboy.PluginManager.SetPluginEnabled (System.Type plugin, Boolean enabled) [0x0004a] in /home/boyd/projects/tomboy/Tomboy/PluginManager.cs:659 at Tomboy.PreferencesDialog.PluginStateToggled (System.Object sender, Gtk.ToggledArgs e) [0x0003d] in /home/boyd/projects/tomboy/Tomboy/Preferences.cs:497 at (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_ToggledArgs (object,Gtk.ToggledArgs) at Gtk.CellRendererToggle.ToggledSignalCallback (IntPtr arg0, IntPtr arg1, IntPtr gch) [0x00000] at (wrapper native-to-managed) Gtk.CellRendererToggle:ToggledSignalCallback (intptr,intptr,intptr) at <0x00000> <unknown method> at (wrapper managed-to-native) Gtk.Application:gtk_main () at Gtk.Application.Run () [0x00000] at Gnome.Program.Run () [0x00000] at Tomboy.Application.StartMainLoop () [0x00000] in /home/boyd/projects/tomboy/Tomboy/Utils.cs:888 at Tomboy.Tomboy.StartTrayIcon () [0x00011] in /home/boyd/projects/tomboy/Tomboy/Tomboy.cs:79 at Tomboy.Tomboy.Main (System.String[] args) [0x000a2] in /home/boyd/projects/tomboy/Tomboy/Tomboy.cs:46
Created attachment 77871 [details] [review] Patch for minor cleanup and simple Bugzilla Plugin Prefs UI
Created attachment 77872 [details] Preview of Bugzilla Plugin Preferences UI Not sure why my screenshot didn't capture the window decoration (likely Compiz/Xgl), but this is what's implemented in the latest patch.
Created attachment 77873 [details] [review] Fixes the issue mentioned in comment #19
Created attachment 77875 [details] [review] Patch that's practically ready for check-in. Fixes these additional things: * data/tomboy.schemas.in: renamed setting "plugins" -> "enabled_plugins". Also disabled the BugzillaPlugin by default. * Tomboy/Preferences.cs: Ditto. * Tomboy/Plugins/ExportToHTML.cs: Fixed up leaks so it shuts down cleanly when being disabled. * Tomboy/Plugins/NoteOfTheDay.cs: Ditto. * Tomboy/Plugins/PrintNotes.cs: Ditto. * Tomboy/StickyNoteImport.cs: Ditto. Other various lines fixed (that were too long).
The NoteOfTheDay plugin shouldn't have to add itself to the "Tools" menu anymore. Since it's something that runs for every note and isn't really an action on the note, it should be modified to just be "on" if the plugin is enabled and "off" if it's not.
This is really nice! One thing to consider, "open plugins folder" seems to be a more "global" option, I would move it down one level, left to the ok button. It makes more sense there.
I checked the configurable plugin interface into CVS yesterday. I'll create a separate bug to track the NotD issue.
(In reply to comment #25) > This is really nice! Thank you! :-) > One thing to consider, "open plugins folder" seems to be a more "global" > option, I would move it down one level, left to the ok button. It makes more > sense there. I believe the bottom area of a dialog belongs to dialog manipulating actions ("Close", "Apply", "Cancel", ...). Well, but you could argue that the HIG also allows to place the "Help" button on the left side of the dialog, so I could place the folder button there. Well, but to my knowledge the HIG reserves that left part of the dialog for the help button, but only the help button.
Can we remove "Open Plugins Folder" from the Tomboy applet's right-click menu now?
Well, I guess we're in UI freeze now. Still, I think that menu option is redundant with Mathias' recent work.
Thinking about it... do we even need the "Open Plugins Folder" exposed in the UI? No other app I know does this (GEdit, Evolution, Banshee).
I think Alex's original intent with the plugins folder was that ordinary people would be able to download new plugins not shipped with Tomboy and quickly "install" them by placing them into the plugins folder. In practice, I'm not sure how often this actually occurs. Instead, another option might be to add in the ability to "install/uninstall" plugins from the plugin preferences dialog that would essentially provide the same functionality.
You would run into the problem that users want to uninstall plugins supplied with banshee, e.g. provided by the same package. Really I think, if a user needs to install a 3rd party plugin (are there any?) he/she can copy them manually - or the distribution should offer a package. I'm not a fan of plugin installation stuff. It makes sense for firefox where there is a huge base of user created extensions but for tomboy... most plugins will ship with the main app anyway.
Contra: As someone capable of creating plugins I often wonder were to install them. This folder button gives potential plugin developers an easy start. I'd even extend the user visible plugin feature in that way, that it contains a .desktop file pointing to "http://live.gnome.org/Tomboy/PluginHacking" to give potential plugin hackers an more easy start. Btw: Realizing quite shocked right now, that Nautilus doesn't offer hooks anymore for reaching your script and template folders. Must file a bug report!
Leave it in then... but really... a developer who has to learn about the API will have no problem discovering the various plugin folders. And about the nautilus scripts: please don't file a bug about this, it has been discussed to death more than once. And keep in mind: it has been gone for a few releases, so it's "feature" even the advanced user will probably only need once every few years
Modifying default assignee and qa contact to be tomboy-maint@gnome.bugs.