collin@xxxxxxxxx (2001-05-20 at 1535.17 +0200): > 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. You can request IRC / mail logs, maybe someone has them. > First of all a definition of the problem area: what are considered > plug-ins? Everything that goes into the directory 'plug-ins'? > Anything else? Some modules too, like the colour selectors, could be considered "plug-ins". > When talking about scripts earliers, I noticed that there is no clear > way of distinguishing which scripts belong in the core distribution > and which don't. I suggest we tackle this problem (first?). Scripts depend on the interpreter, so that would mean the interpreter should be in core app, which is not bad, but also not necessary. Scripts are plugins for plugins. > 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; I doubt Gimp will provide more, the idea is to have a small system where you plug things as needed, even GUI will be separate (and that for me is plugable). This general idea can be read in somewhere, this list archive probably. > - those that will help other plug-in authors better understand how to > write plug-ins; That should be in a devel package. Why do a user need a plugin that does nothing or near nothing? It is like the test script fu, lots of controls and you get a plain ball. Or like devel packages, users do not need to waste space with .h files that will never use. > - those that will make the GIMP look good when compared to other > raster image editors; and Then you include all those working, so you are sure you are giving the maximum you can. > - those that perform a task the best in its field. I doubt there are repeated plugins, people do not code to have two, they patch instead. And if they did not know, they try to join the work, or deprecate the bad one. > Can such a distinction be made? Yes, but you forgot: - plugins that are maintained. I think your point of view is what users want / need and the real thing is what volunteer coders can do. And from that comes the idea of reducing the number of core plugins, moving the rest to 1..N packages. That or somebody finds a way to keep all plugins updated (pay a coder with comunity money like with a Perl one? create a company to support it?). :] GSR
