> Do you volunteer?
No, but I did. I just created an almost empty plug-ins/gpim (on
sourceforge), gpim = gimp plug-in manager (does anybody have a good
expansion for "mel"? :)
The first step for redistributable plug-ins is the plug-in layout
every plug-in is stored in a subdirectory with it's own name, or a
subdirectory with it's name+version (when it was stored in a versioned tar
Inside, we have the following structure (source package):
contains .pot files and .po files. I guess this is the common standard
anmd will stay for some time. Every successor must be able to manage .po
files in some way, and maybe we can manage this more intelligent (using,
say, a translation server that collects .pot files from plug-ins and
updates them, easing both translator work and programmer work. Hey, that
could be web-based!).
contains a description, version, type fetch information, status etc..
This would be a good candidate for an XML application, but I do not want
to drag in eitehr XML::Parser nor gnome-xml, nor any other external
reference. Maybe it gets similar to the PPM format.
Can be used to generate the Makefile. Somehow we must communicate some
gimp-settings to the plug-in, but setting GIMPTOOL and related envvars
xxx/Makefile (this must somehow get generated, of course)
it should have some standard targets (make dist for example, for
creating source distributions, and bindist for making a binary package).
a long description.
Binary packages would look like:
this would be similar to the source, except that it also contains
architecture information (e.g. config.guess output), should be
autogenerated form the normal plug-in.def
contains the subdirs "brushes", "gradients", "modules", "plug-ins", e.g.
a partial mirror of ~/.gimp, so plug-ins can create their own
subdirectories by putting them here)
Of course, if I forgot anything... now step 2, managing and distributing
for plug-ins on sourceforge this would be easy. Just educate the people
about their plug-in.def and the common layout.
Source and binary distributions would be uploaded to some common place
(preferably), say download.sourceforge.net, or they reside at the place
stated in the plug-in.def.
The manager program would then fetch the plug-in.def of all plug-ins
and would synthesize a common database at a common place (e.g.
http://plug-ins.gimp.org/plug-in.db.gz). This database could be downloaded
by gpim on the "end-user" side. The end-user could then select the package
(getting a short description of what it is), or the README (which will be
fetched via the net).
Then he would have to choose between different versions (e.g. the latest
stable and the latest experimental release) and any precompiled binary
packages we happen to have.
After that the package would be fetched (cd-rom, net..) and installed
either as user-only or systemwide, and do any magic necessary to update
the translation tables (if at all possible ;) BTW: we need to consult
a ~/.gimp/po/ directory for translations as well at some point in the
Here is an example of a plug-in.def file, for a binary
plug-in (this draws heavily on the ppd format described in
<SOFTPKG NAME="GPIM" VERSION="0,1,0,0">
<TITLE>Gimp Plug-In Manager</TITLE>
<ABSTRACT>GPIM is a coonvinient tool to manage gimp plug-ins</ABSTRACT>
<AUTHOR>Marc Lehmann <[EMAIL PROTECTED]></AUTHOR>
<CODEBASE HREF="GPIM-0.1.tar.gz" />
<DEPENDENCY NAME="gimp-perl" />
perl Makefile.PL ;;
make install ;;
<OS NAME="Linux" />
<ARCHITECTURE NAME="i686-pc-linux-gnu" />
<DEPENDENCY NAME="gimp-perl" />
<CODEBASE HREF="GPIM-0.1-i686-pc-linux-gnu.tar.gz" />
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |