Re: [gedit-list] Gedit Plugins - Unofficial Enhancement Proposal

[Steve Frécinaux <nudrema gmail com>]

On Fri, 2007-02-23 at 12:11 +0100, Trond Danielsen wrote:
> 2007/2/23, Steve Fr�naux <nudrema gmail com>:
> > On Fri, 2007-02-23 at 00:40 +0000, Zeth Green wrote:
> > > 1. Single Plugin Format
> > >
> > > All plugins have a .gedit-plugin file. However, beyond that, at the
> > > moment, plugins can be organised in two ways. They can be a single
> > > file, or they can be a directory. This inconsistency will make it very
> > > complicated for graphical plugin installation and especially
> > > uninstallation.
> > >
> > > I propose a single format. All plugins will basically follow the
> > > directory approach, but the gedit-plugin file will be inside the
> > > directory.
> >
> > This is mostly an implementation matter. If you have some graphical
> > plugin manager, he will deal with that by itself. You download the
> > tarball and the GUI installs it correctly. That's how the theme manager
> > works fwiw and there is no problem about that. BTW you seem to forget
> > there are also C plugins (yeah, a third "format", even harder to
> > install).
> >
> 
> Wouldn't it be easier to add and remove plugins if the plugin engine
> did a recursive search through the plugin folders? That way each
> plugin could be installed in separate folder, instead of having all
> .gedit-plugin files in the "root" folder?

Maybe, the remaining issue is that the directory tree can be quite deep
(for python plugins, or useless data, or whatever)
Anyway it's true we could have one dir per plugin, then "recurse" only
to the first subdirectory, while remaining compatible with the current
system (backward compatibility matters)

Patches encouraged ;-)

> > > 5. No bundled plugins.
> >
> > I don't agree. Bundled plugins are either there for ages (when nobody
> > even knew gedit supported plugins) or functionnalities that are so great
> > we want them as visible as possible. Some are even activated by default,
> > and we can't reasonnably implement it as part of the core. More,
> > packaged plugins (either gedit or gedit-plugins ones) come with full
> > support for i18n, and that's important.
> >
> 
> Given that there is a easy way to add plugins, I think that moving as
> many plugins as possible out of the core gedit package, would actually
> boost the entire plugin collection. Currently the best plugins are
> allready included in gedit, and I believe that many of the other
> plugins get very little attention because of this.

They could be packaged as a separate package I guess (well it's actually
up to the distros) but it's way harder for C plugins to be "distributed
as tarballs", because, hey, it's C, so heavily depend on what you have
on your system, and that's why apt, yum or emerge are for.

> I think the way the gnome theme manager handles additional themes is a
> good way to solve this. Dragging and dropping new themes into the
> plugin dialog should automatically install them in the users plugin
> folder.

Another side issue is that our plugin is not smart enough: it has no
idea of plugin versions and has only gained the ability for python
plugins to know the gedit version lately. C ones can do so but only at
runtime. I guess we should add some fields to our .gedit-plugin file,
like the plugin version and the gedit version is is for.