The descript file format is templated in plugin_package_template.txt. A descripion of the fields is included in plugin_package_descrip.txt. This file is more general info about my ideas, and why i came to the conclusions I did, and requests for comments on specific items ( the whoel shebang is open to discussions also of course ). Most of the ideas presented here are based heavily on rpm/rpm-find and deb/apt-get. Simplified alot however I hope. ** The Problem ** Plugins are a pain. At one point, their origins were flung far and wide, the steps to build them were numerous, and their was no standard way of obtaining info about them. The plug-in registry has helped with the first problem tremousdely. In general, all plugins are listed in the register, with the occasional exception (those that go straight to cvs, etc). The second problem was allivieated to a great extent with the inception of the wondrous `gimptool`. It may compiling and installing single file plugins easy. This make building most plugins easy. The third problem isnt as sever as the first two, but it makes it difficult to "browse" plugins. Especially in any kind of generic way. You cant say "go get all the render plugins", or "are there any other file plugins?". Hopefully we will be able to help that abit. But those are just user issues, the current state of plugins has a whole different set of issues for gimp maintainers. It is extremely difficult and time consuming to determine if the dist has the latest version of some plugin. The result is that dist's often ship with outdated and buggy plugins. Another issue is the trouble of feeding back changes to plug-in authors. Currently, gtk and gimp change rapidly, and often plugins need to be modified in cvs to work properly. At the moment, there is no good way to notify the plugin authors of such changes. And not doing such is a problem in itself, as it breed contempt amount plugin authors, and often results in fixes not getting merged properl, etc. A final issue that faces the dist maintainers is, if they decide to include a plugin in the main dist, they need to adapt it to the existiin build enviroment. Since plugins often use a whole variety of build methods, this can sometimes be very difficult. ** a proposed solution ** The arival of `gimptool` and the plugin registry helped the plugin situation alot. But things need to go one step further. The basic idea here is to design a gimp plugin "package" format. With an emphasis on being simple, easy to build, easy to use, and with enough info embedded in it. The basic model is the same as used in linux distributions like Red Hat or Debian. A standardized package format, that is easily installed. While those are primarily geared towards binary packages, they also have very useful source package design. The design of this package format was based heavily on the ideas in deb's and rpm spec files. Eventually, I would like to be able to setup a web server with a tree of _static_ info derived from the description file for the packages. This is similar to the way rpm-find/rpm2html and the Debian apt package manager work. A user can request a package, which checks on a server, and returns an info file for that package. If the user likes the info, they can then download the package and install it. An example session might be like: -------- bash% gimptool-find sel_gauus checking plugins.gimp.org.... found sel_gauss.gp plugin: Selective Blur Author: Thom van Os url: http://selguas.org email: thom@vanos.com Version: .0002-blackbird Serial_num: 4 Build_date: Mon Mar 22 05:50:52 EST 1999 Type: Image Menu: /Filters/Blur/Selective Gaussian Blur Description: This filter functions similar to the regular gaussian blur filter except that neighbouring pixels that differ more than the given maxdelta parameter will not be blended with. This way with the correct parameters, an image can be smoothed out without losing details. However, this filter can be rather slow. Install this plugin: ? y gimptool --install sel_gauss.c egcs -g -O2 -Wall -I/usr/X11R6/include -I/usr/local/lib/glib/include -I/usr/local/include -o /home/aklikins/.gimp-1.1/plug-ins/sel_gauss sel_gauss.c -L/usr/local/lib -lgimpui -lgimp -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm -------- Wouldnt that be slick? I tend to prefer a static tree of data, like rpmfind and apt use, but a cgi based version querying some kind of database could be doable also. But the static one would be more easily mirrorable. ** Package Format ** The basic package format is simple. A gzipped tarball. The description file would probabaly be distributed outside the tarball. For simplcity, you would probabaly even include one source files in a gzipped tarball. The advantage being that no special tools are required to make the package, to query the package, or to install the package. Of course special tools could be developed to make doing so even easier, but shouldnt be required. ** server setup ** This could be a little bit tricky if we want a static rpmfind style tree of info. The server would probably include a largish file for meta info containing basic info for all the plugins available (maybe name, type, and menu_path?). More info might be useful here, and it would be too large. (for example, with just about every plugin under the sun, my pluginrc is about 370k, non compressed.) This file would primarily be for doing "apropos" searches, since you dont want to download every descrip file whenever you want to search for "moss" in the plugins. I would tend to base this on the "fullindex" file rpmfind uses. It includes a name, a summary, and a url for more detailed info file. The rpmfind util uses a hierarchal XML file for this. The most obvious way to divide this would be my menu placement i think. Since the user will probabaly want "more render plugins" or " some file plugin.." Having info organized that way would also make the most sense for gui "plugin" browsers (akin to apt-find/gnorpm). Then for each plugin, the server would have a more detailed file, that would include stuff like version numbers, and download urls. If the user decides they are interested in some plugin, they get the detailed info file from the server. If they then decide to download it, they grab it from the url in the file. Of course, all the server side stuff would be generated by some kind of duct tape/perl magic, perhaps once a day or however often. Alternatively, this could all be done via some sort of cgi database query/search engine. ** misc details and comments on implementation ** build_method we limit the package build methods to these three for sanity sake. The prefered methos is the gimptool, as this provides very predictable build and install process. The second prefered method needed by multifile plugins is to use a Makefile. This Makefile should make use of gimptool for finding out any lib and header paths. An example: CC = gcc GIMP_LDFLAGS=`gimptool --libs` GIMP_CFLAGS=`gimptool --cflags` CFLAGS = $(GIMP_CFLAGS) -O2 -Wall LDFLAGS = $(GIMP_LDFLAGS) -lm all: sel_gauss install: sel_gauss gimptool --install-bin sel_gauss sel_gauss: sel_gauss.c $(CC) $(CFLAGS) -o $@ sel_gauss.c $(LDFLAGS) clean: -rm -f *.o core sel_gauss These make files should include at least a standard "all" target and a "make install" that uses gimptool. This makes the behaviour of the makefile as predictable as possible. The third option, preferably only used in the rare occasion where it is neccasary to know about external libs and other options is to use a configure script. The plugin should be buildable with just: "./configure && make install" ie, the configure should be setup so that their is no need to specify "--with-gtk" or whatever. Ideally, we can get a template auto*/configure setup that people can easily modify for this purpose. build_flags: This could be a usefule option, but we need to give gimptool the ability to add arbitrary flags to its output. soemthing like: gimptool --extra-flags -lGL -lgck -lart --build some_3d_plugin.c This would probabaly help cut down some on the number of plugins that needed makefiles and such. _RFC_: Are the above options enough? or should we go to an rpm spec file style (or the euilivent "rules" of debs) of %build CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=/usr/X11R6 \ --enable-utmp --enable-wtmp --enable-xpm-background make %install make install cp docs/* /whatever/package_name/docs This would certainly be more powerful and flexible. But the security implications are kind of frightening. Especially, since the idea here is to make this easy for newbies, even to the point of them not having to know that somethings being compiled. docs: Not sure if this is useful, or how to implement it. I suppose we could just add some stuff to gimptool so we can specify a docs path, ie: gimptool --docs /usr/local/share/gimp/plugins/docs gimptool --install-docs foo_package cp docs/* /usr/local/share/gimp/plugins/docs/foo_package/ something to keep in mind I suppose. i18n: Something this format doesnt cover at all is translations. rpm spec files handle this to some degree by providing muliple versions of fields tag with the approriate locale. ie: %description Rxvt is a VT100 terminal emulator for X. It is intended as a replacement for xterm(1) for users who do not require the more esoteric features of xterm. Specifically rxvt does not implement the Tektronix 4014 emulation, session logging and toolkit style configurability. As a result, rxvt uses much less swap space than xterm - a significant advantage on a machine serving many X sessions. %description -l de Rxvt ist ein VT100-Terminal-Emulator für X. Es ist als der Nachfolger von xterm(1) für Benutzer gedacht, die auf die exotischeren Funktionen von xterm verzichten können. Insbesondere implementiert rxvt keine Tektronix 4014-Emulation, keine Sitzungsprotokolle und keine Konfigurierbarkeit im Toolkit-Stil. Als Folge davon belegt es wesentlich weniger Auslagerungsplatz als xterm, was einen signifikanten Vorteil für Computer bedeutet, die viele X-Sitzungen bedienen. I could see adding a _de or whatever to each of the fields if need be. But for the time being, I say we avoid it in the name of simplicity. cross platform issues/patches: spec files include an option to apply any given set of patches to a apps pristince source for "redhatifying" and porting issues. Something to keep in mind. For now, I say avoid it in the name of simplicity. _RFC_: Do we need a checksum included? We could include a checksum of the tarball that accompanies the descrip file. This might be a useful way to check for corrupt packages. But it is also probabaly too complicated. _RFC_: Should we include a package manifest in the descrip file? Might be useful for troubleshooting, but it probabaly also adds a bit to the time to make a pakage for limited use. _RFC_: Lots of plugins require info to be stored in the gimprc, but dont put it there themselves. Should the package format and/or gimptool be smart enough to figure it out? Perhaps we should include this as a field just to make it info available to the user? _RFC_: do we need a list of EXTRA_DIST? Or can we just assume that any program that needs to install extra info (brushes, patterns, etc), will use a Makefile that will take care of it? _RFC_: It wouldnt be too difficult to combine the info file and the tar ball together. ie, cat blur.info blur.tar.gz > blur.gpf And then just make the perl server script or gimptool seperate them. I have no idea if there would be any reason to do such though.