"Branko Collin" <[EMAIL PROTECTED]> writes:

> Am I to understand that there is no recorded instance of this 
> discussion? Well, let's start now, then, so that next time we can 
> point to the mailing list archives.

The mailing list archive definitely has at least parts of this 
discussion. Since we did not come to a conclusion last time, the 
archive is however not very helpful and you are right in pointing 
out that we should start it all over now. 

> First of all a definition of the problem area: what are considered 
> plug-ins? Everything that goes into the directory 'plug-ins'? 
> Anything else?

Scripts are definitely in the same category. In the future we will
also see pluggable tools and its foreseeable that we will face the
same problems there at one point.

> My suggestion is that the following plug-ins belong to the core 
> distribution:
> - those that perform a task that the GIMP should have provided for 
> itself or will provide for in the future;

Our goal is to have as much functionality as possible in plug-ins.
This reduces the size of the core, makes it cleaner and improves
maintainability of the core. This makes this rule questionable
especially since "a task that the Gimp should provide" is much too

> - those that will help other plug-in authors better understand how to 
> write plug-ins;

We have a plug-in template for this task and I don't see what would 
stop plug-in authors to have a look into the plug-in packages that 
are distributed seperate from the core gimp package.

> - those that will make the GIMP look good when compared to other 
> raster image editors

Only because another program has a certain functionality does not 
make it necessary to distribute the same functionality with core Gimp.

> - those that perform a task the best in its field.

Not a very useful definition either. Those plug-ins will most likely 
be pretty large and only useful to a subset of users. Thus they belong
into a special package.

> Can such a distinction be made?

You are right that we need to make such a distinction, but I don't
think the rules you suggested make much sense. On the other hand I
think we should first discuss how the gimp packaging should look
like in the future instead of tackling the problem which plug-ins 
go into which package.

I'll try to summarize some of the ideas that have come up during
earlier discussions:

A very important point for distributing a plug-in is to have a 
maintainer that feels responsible for it. The core Gimp maintainers
would like to only have a set of basic image manipulation tasks
in the core package and they would feel responsible for keeping them 
up to date, handling bug-reports and discussing patches. Such basic 
plug-ins would include for example Blur, Gauss-Blur, Sharpen, Rotate,
and a set of important file-plug-ins to give only a few examples.

Other plug-ins could be grouped into smaller packages for special
purposes. For example there could be a gimp-web-plug-ins package
that adds functionality like GIF-Save, Anim-Optimize, ImageMap and
others. Such a package would have a maintainer who is responsible
to handle bug-reports and keeping the package in sync with the core.

Installing gimp would then be a process of installing gimp-core
and a set of plug-in packages that fit the needs of the user. Such
an approach has some obvious advantages but also a bunch of 

The packages would have interdependencies. The web-plug-ins package
might include a gimp-perl script so it would require gimp-perl. Of
course everything in the web-plug-ins package but this script would
work w/o gimp-perl so actually gimp-perl is not required but only
recommened. I can however only think of one binary package system 
that can handle those kind of weak interdependencies (debian).

The packages should not overlap and they should share the menus
intelligently. This would require some interaction between package
maintainers. I think however that this should be doable.

On multi-user systems the administrator who installs gimp can not
decide what packages the users might want. One solution is to 
install them all. This would however lead to overcrowded menus.
A problem that could be solved by a plug-in manager that knows 
about all plug-ins that are available and lets the user choose
what plug-ins she wants to see in the menus.

Having gimp split up into dozens of packages will make installation
difficult. Again a plug-in manager that knows about all available
plug-ins out there, collects and installs them would help.

It turns out we need a plug-in manager. What functionality should
such a beast have? Here's a list of things that came to my mind:

It should read a number of plug-in lists: a list of all available
plug-ins that is distributed with the core gimp and can be updated 
through the web. A list of plug-ins that are installed locally do
not necessarily appear in the menus.

It should have meta-packages of plug-ins similar to the task-lists
Debian has so a user can install a bunch of plug-ins with a single
click. One meta-package would be "All plug-ins", other tasks could
be "Web Publishing", "Photo Retouching", ...

It should be able to download and install precompiled binary 
packages or download sources, compile and install them. A solution
for the binary packages would be to use the binary packaging 
system provided by the distribution. Since there are a bunch of
different distrbutions out there, this might be tricky.

That should be enough food for thought for now. Please comment.

Salut, Sven
Gimp-developer mailing list

Reply via email to