Re: [gedit-list] Project management, subversion/SCM integration

["Vic Fryzel" <vic fryzel gmail com>]

Sorry, hit reply instead of reply to all in my previous post.

On Mon, Nov 24, 2008 at 11:01 AM, Jesse van den Kieboom <jesse icecrew nl> wrote:

I'll have to fully disagree with this. There is no need for all kinds of
different plugins that basicly do the same stuff, but with different
underlying systems. Abstracting certain common functionality does not
mean that specific backend systems cannot provide additional
functionality on top of the common ones.

This would imply something different that what I think you're referring to, though.  This would imply support from the base system for the plugins to signal, so that the plugins would be able to implement that extra functionality on their own, and have it show up in the UI.  I agree that abstracting certain functionality doesn't mean that specific functionality can't be provided, however if the plugins are just going to register a bunch of commands in the UI, abstraction doesn't get us much in this case, but rather an interface does.

I don't agree here. I'm not suggesting that we would distribute all
systems with the plugin, but the plugin should serve as a common
framework. You can download/install additional backends which are
plugged in to this plugin. This ensures a consistent
look/feel/integration and maintainability. Of course this kind of
functionality will not be put in the gedit core. gedit is first and
foremost a simple text editor. There is no need nor use for such SCM
integration in the core. This is exactly what the plugin system is for.

I have to say, I entirely feel that this is exactly what I was referring to when I started this thread.  But I disagree with not putting these abstract extensions into core.  I think that a plugin with child plugins won't get us as far as just putting a bunch of UI extensions/common interface into gedit, and removing the middle man.  I think that if we need a plugin to extend the gedit framework, then the gedit framework should be extended to support the plugins directly.  It's either:

 * a plugin that implements an abstract "commit" method, which in turn loads a child plugin to execute the commit method.  Here, the abstract commit method's class would register the method with gedit.

 * or, plugins load themselves into the gedit via a standard interface with the UI

I don't think that abstracting out the loading in the former will be very advantageous, as it would be hard to circumvent for specific functions.
 

Why not, all these plugins will diverge, will have a different look and
feel, different functionality and a lot of things have to be separately
maintained, even though there is much common ground. And yes, I think
this plugin, when properly developed, should go into the gedit-plugins
package.

I don't disagree assuming they're distributed in the gedit-plugins package.

-- 
Vic Fryzel (vic dot fryzel at gmail dot com)