"Guillermo S. Romero / Familia Romero" <[EMAIL PROTECTED]> writes:

> I would make a basic plugin handler so users can remove / add them to
> menus, if installed, and let the real task of getting the plugin to
> user / pkg system / whatever. If you use a pkg system, it can do it
> for you better than anything, if not, there is a make install target
> or a gimptool mode for that. I do not think becoming another Red
> Carpet is worth the time (which in place seems to be APT with GUI).
> So I would split the system more at source level, so you get x groups
> and build & install them (or make distro pkgs then install) following
> an order, like you can do with GNOME, ie. ATM I already use that (with
> x=2): gimp and gimp-data-extras.

actually this is my opinion too. I'm not convinced that we should try
to deal with binary packages. This is one of the ideas that has come
up and that I remembered, but I second your thoughts about it.

IMHO the best solution will be to have a bunch of standalone source
packages that follow some well-defined rules. One rule should be that
there needs to be a file that describes the package and all its 
components that can be used by the plug-in manager and by the next
generation plug-in registry. Ingo had an XML format in mind and I was
hoping he would post a proposal to this list, but I haven't seen it

For the moment we want to keep all plug-ins in the core package until
we have ported Gimp to Glib/GTK+-2.0. This is because we think that 
a lot plug-ins will be ported very easily and having them all in one
place might ease this task. Once the port is done (and we are going to 
start it very soon now), we should think about moving most of the 
plug-ins out of the core CVS module. Hopefully we have made up our mind
on the new plug-in system until then. 

Salut, Sven
Gimp-developer mailing list

Reply via email to