gimp/HACKING

Requirements
------------
If you want to hack on the GIMP project, it will make your life easier
to have the following packages (or newer versions) installed:

	- GNU autoconf 2.13
	- GNU automake 1.4
	- GNU libtool 1.3.4

These should be available by ftp from prep.ai.mit.edu or any of the
fine GNU mirrors.  Beta software can be found at alpha.gnu.org.

	- pkg-config 0.7.0 (or a newer version)
		
Available from http://www.freedesktop.org/software/pkgconfig/.

	- intltoolize 0.17 (or newer version)

Available from ftp://ftp.gnome.org/pub/GNOME/stable/sources/intltool/.


Compilation
-----------
If you are accessing gimp via CVS, then you will need to take several
steps to get it to compile.  You can do all these steps at once
by running:

        cvsroot/gimp# ./autogen.sh

Basically this does the following for you:

        cvsroot/gimp# aclocal; automake -a; autoconf
        cvsroot/gimp# glib-gettextize; intltoolize

        The above commands create the "configure" script.  Now you
        can run the configure script in cvsroot/gimp to create all
        the Makefiles.

Before running autogen.sh or configure, make sure you have libtool in
your path. Also make sure glib-2.0.m4 glib-gettext.m4, gtk-2.0.m4,
pkg.m4 and intltool.m4 are either installed in the same
$prefix/share/aclocal relative to your automake/aclocal installation
or call autogen.sh with

	'ACLOCAL_FLAGS="-I $prefix/share/aclocal" ./autogen.sh'.

Note that autogen.sh runs configure for you.  If you wish to pass
options like --prefix=/usr to configure you can give those options to
autogen.sh and they will be passed on to configure.


CVS
---
If at all possible, please use CVS to get the latest development
version of gimp, as well as the CVS version of gtk-doc, glib, pango,
atk and gtk+.  You can do the following to get them all from cvs:

   $ export CVSROOT=':pserver:anonymous@anoncvs.gimp.org:/cvs/gnome'
   $ cvs login
     (there is no password, just hit return)
   $ cvs -z3 checkout gtk-doc glib pango atk gtk+ gimp

We will try our best to keep the GIMP CVS tree compileable against
the latest development releases of glib, pango, atk and gtk+. Since
it is sometimes difficult to get a working state out of CVS, you may
prefer to use these releases instead. Get them from 
ftp://ftp.gtk.org/pub/gtk/v1.3/. We don't expect the API of these
modules to change anymore. If it does nevertheless, we will adapt
GIMP in CVS. This means, GIMP from CVS is supposed to compile against
glib, pango, atk and gtk+ from CVS. Most probably however, the latest
releases will do also.


Patches
-------
Please submit patches to the gimp-developer@lists.xcf.berkeley.edu
mailing list.  All kinds of contributions are appreciated. Larger
patches should be uploaded to ftp://ftp.gimp.org/incoming/. Follow
the rules there for naming your patches.


Autogenerated Files
-------------------
Please notice that some files in the source are generated from other
sources. All those files have a short notice about being autogenerated
somewhere at the top. Among them are the files ending in _pdb.[ch] in
the libgimp directory and the files ending in _cmds.c in the app/pdb
subdirectory. Those are generated from the respective .pdb files in
tools/pdbgen/pdb. The list of contributors is used in several files
which are for that reason generated from the file contributors in
tools/authorsgen.


Hackordnung
-----------
We encourage you to follow the GIMP coding style throughout the GIMP
project.  For the core components (application and libs) this coding
style is enforced.  The GIMP coding style is defined as follows:

  Function names are lowercase, words separated by underscores.
  Macros and enums are all uppercase, words seperated by underscores.
  Types are all words capitalized, no separators between words.

  All functions in header files need to be prototyped.

  Indentation rules are GNU coding style, in particular:
    - 2 characters indentation level
    - Do not use tabs (of course your editor can use tabs, but it 
      should write them to file as 8 spaces each).
    - Opening brackets are on a new line and indented one level.
    - Function header have the return type on one line, the name
      starting in the first column of the following line. All
      parameters are prototyped and there's a new line for each.

Try to make use of GLib's object system as much as possible. Do not
create wrappers around functions of parent classes. If you end up
duplicating code, try to create a common parent class and implement
the common methods there.

Don't include headers in headers except where unavoidable (e.g. for
deriving objects). Opaque typedefs go to app/base/base-types.h,
app/core/core-types.h etc.

Don't use the GTK wrappers around the GLib object and signal system.

One goal of the 1.3 development branch is to make the GIMP code more
readable and understandable. Please help us to achieve this goal by
cleaning up the present code and make sure that all new code follows
the coding guidelines.