I recently discovered ClassBrowser for gedit, and its awesome.
But why isn’t it included? I think this plugin is valuable enough for it to be part of gedit, or is there a restriction against using python plugins in the gedit distribution?
I recently discovered ClassBrowser for gedit, and its awesome.
But why isn’t it included? I think this plugin is valuable enough for it to be part of gedit, or is there a restriction against using python plugins in the gedit distribution?
If plugins needs to to be shipped as default – the mechanism for distributing plugins is broken. (Too hard to install is always the case).
“A plugin shipped with the application should not appear as a plugin”
Can’t we add that to the HIG guide? I really think we are using plugins as the easy way out.
Fred, the mechanism is broken. Or possibly, not done yet. It’s always “untar, put (some of these files) in this special directory which you may or may not know how to find, then find the hidden deep in preferences plugin tab, then find your plugin and enable it”. Shipping by default, on the other hand, means in a separate package, which arbitrarily contains some plugins someone thought useful, and not others others may find useful. Pretty much random, as it’s all one package that easily would be too bloated, but at the same time must contain some bare minimum.
Firefox does this wonderfully, both with the main addons site and with standalone .xpi. GNOME could too, with a standard system that worked something just like that. Ideally, there would be one plugins directory (~/.config/plugins ?) that held in turn the directories for gedit, epiphany, and all the others. Then there would be a common GUI that all these apps could use to install, manage and remove their plugins. Now I think they even all got their own package format…
Classbrowser is somewhat great – it is great for some languages, those that had special work, but the ones that need ctags, not so much. I’d really like to see it get some more attention, though, I’ve had lots of helt from it.
Somehow plugins/addins-installation is great in Java (eclipse, netbeans) and Mono (banshee, monodevelop, f-spot!)
Perhaps it’s because of the dependency on ctags.
Usefulness is not the only criterion to make a plugin shipped in an official distribution, be it gedit-plugins or gedit itself.
There are something like author agreement (if the author cannot maintain its own product in the Gnome SVN, or looses his god-like privileges on it, he’s not gonna agree to put it altogether with the other “official” plugins. Also, code quality is a factor. Does it conform with other plugins when it comes to code conventions, efficiency, clarity, organization or whatever?
About the distribution issue, I think that it’s mostly distro work. Then there can be some pakagekit frontend or whatever to have a nicer UI than the one with all your distro packages. But I don’t think being able to unpack automatically any python plugin is a good thing. First it is not secure at all, and second it doesn’t solve the issue with compiled (C) plugins.
There are many others interesting plugins.. Here an installation script:
http://github.com/grigio/gedit-rails/tree/master