GSR - FR wrote:


Yes, we should definitely try to get some projects this time. I'll add a
draft of my project proposal below. Comments, suggestions and
corrections are welcome.

I'm volunteering to be a mentor for this one as well, unless the
discussion shows that my knowledge isn't sufficient and someone else
wants to take it.

Resource contribution, distribution and management system

The initial idea:

Provide a system that allows anyone to contribute and maintain resources
(brushes, palettes, scripts, plug-ins, ...) for GIMP, and have it
organized in a way that makes it easy for GIMP users to access these

The situation at present:

There is one bigger hub for plug-ins and scripts, the so-called GIMP
registry, at It is used by some script and
plug-in authors, but not well known to GIMP users, because it is
somewhat hard to find useful things there. It is maintained on a low
level, basically "keep it working". There are not standards set for
publishing resources there, some projects are just links to the author's
own pages.

Other resources like brushes, patterns, palettes etc. are spread over
the web, with some larger collections at Deviantart,, and the GIMP User Group,

This splits the community a bit - many people don't know about the
brushes at Deviantart, for example.

Another problem is the local resource management in particular
installation. For novice users or users who aren't familiar with files
and folders, it isn't obvious where to put downloaded files (or even
that you have to extract them from an archive).

The tasks:

The project consists of two main parts, one called "Server" and the
other "Client".

1. "Server" part

Build a resource contribution and distribution system that allows
authors to publish their resources easily, provide them with
everything that is needed for a good presentation (like adding previews
or example images) and allow contributions to existing resources (e.h.
binaries of plug-ins for several platforms, this would be popular for
Microsoft Windows or Mac OS X). Users should be able to learn about new
and updated stuff, and browse and sort the collection by a number of
attributes - version, gimp version, intended use (image manipulation,
image creation, filter type, colors, ...).

An example might be ccHost, which is used for e.g. ccMixter, However, this is probably too complicated for this
purpose - think more like Flickr.

This system will most likely be web-based and usable with a normal
browser, though it could allow for other backends (FTP, WebDAV, CVS/SVN)
as well.

Scalability is a major concern for us - if "slashdotting" means
something to you, then you'll know what we're talking about. The system
may (and probably has to) use a database to store metadata about some of
the resources, but it shouldn't access the database for read access -
the pages only have to be updated when a change occurs. This will also
make it possible to create static mirrors more easily.

Security is another concern - signing resources should be possible and
even required for things like binaries.

The programming language of choice would be Python. PHP and Perl are
frowned upon by many GIMP developers, and Python can also be used for
the second part of the project.

The main goal of this part is to replace

This task includes:

- familiarize with the types of resources that can be distributed
- investigation of the currently existing gimp resource distribution
sites (Registry, Deviantart, GUG, other?...), analysis of their up- and
- design of the new system (or a plan to customize an existing one)
- coding or adapting, respectively

2. "Client" part

With the perspective of a rather large resource repository in mind,
there should also be a way to access this repository from within GIMP.
The most basic aspect is easy installation of resources, which can be
done for scripts or plug-ins by using gimptool. Extending gimptool to
handle alls resources known to GIMP would be a first step.

However, this type of interface is not what we should force upon our
users. A GIMP plug-in that can access the system built in the "server
part" would be more appropriate. I haven't put much thought into this
part yet, though.

The programming language should be either C or Python - you won't be
able to do this with Script-Fu, for example. Platform-dependency should
be avoided - relying on e.g. apt or rpm would fail for the windows platform.

The inherent danger of this approach is replicating
functionality that is present in package manager on some platforms
already, and thus interfering with these. This should be avoided.

The main goal of this part is to make the new
usable from within GIMP.

This task includes:

- use the server part as a real server
- familiarize with GIMP plug-in programming
- familiarize with local GIMP resource storage
- coming up with a usable UI

The GIMP >      | IRC: irc://
    Wiki >     | .de:
Plug-ins > |

Gimp-developer mailing list

Reply via email to