On Sat, 30 Nov 2002 00:40:52 +1100, David Hodson <[EMAIL PROTECTED]> wrote:
> Wow. Sure is hot in here.
> Some comments, from a gimp _and_ filmgimp developer:
Thanks! I am glad that such a person exists. ;-) And I prefer to
have a serious discussion rather than a flame war.
> I also regret any duplication of effort between the two. However,
> I'm not personally convinced that merging them is a good idea.
> My feeling is that Filmgimp should be a tool specifically (or
> at least, primarily) for the film industry. It is very likely
> to develop along lines that are (at best) not useful to, or
> (quite possibly) totally unwanted by, the more general Gimp
> community. Remember, a tool that can do everything is seldom
> the perfect tool for one specific job. I don't think merging
> Gimp and Filmgimp will necessarily make either set of users
Merging both does not require the removal of features from either
tool. The added value of Film Gimp comes primarily from its 16-bits
support and its frame manager (and specialized plug-ins). But
unfortunately, it is based on an old core, which lacks many features
that are present in the current GIMP (not to mention the plug-ins).
If GEGL and the frame manager were merged into the current GIMP, then
everybody would win because any new feature or bug fix would be
immediately available to everybody. Currently, everything since the
original HOLLYWOOD fork has to be implemented separately in each tool.
Note that merging Film Gimp and GIMP does not mean that everybody
would have to use the same user interface. The split between core and
UI that occured during the development of GIMP 1.3.x means that it
would be much easier now to create a slightly different user interface
that is optimised for working with films. Some features could be
hidden or accessed in a different way if they are not so useful for a
specific version of the user interface.
> Of course, it would be great to build both tools on a single
> code base. But that's a bigger job than just merging the code,
> requires a wider range of skills, and (like everything else)
> is only going to happen if someone wants it badly enough to
> either do it, or pay someone else to do it.
Sure, this is not an easy task. But a large part of it is planned for
GIMP 2.0 anyway.
The two most requested features for the GIMP are CMYK support and
16-bits support. Other popular feature requests are layer groups,
active layers (adjustement layers or styles), EXIF and others, but
they come far behind CMYK and 16-bits channels. So we will have to
add those features to the GIMP soon, probably by using the GEGL
library. Another feature that will be integrated in the GIMP soon is
a macro recorder (and playback). This is also on the Film Gimp todo
list. Same for the support for Python, which has been added to the
Some other features related to the user interface are also requested
from time to time. For example, some users would like to have an
MDI-style interface or at least have the image menu available on top
of the image. Some GIMP developers are against it, but personally I
would like to have this (maybe as an option) because this would make
the GIMP much easier to use for those who do not have a "decent window
manager" (e.g., Windows). Some of these things have been implemented
in Film Gimp. I would like to have them in the GIMP as well and I am
thinking about implementing them myself. But having two separate code
bases implies that any fixes or improvements implemented later would
have to be duplicated. It would be much simpler to avoid these
efforts by merging the code as soon as possible.
So although merging the two codebases is not an easy task, I think
that a significant part of the work will have to be done for the GIMP
anyway. Working on this convergence as soon as possible would also
avoid the duplication of effort that is currently done by trying to
bring Film Gimp closer to 1.2.3 (instead of 1.3.x) and porting it to
Windows and other systems (which would be much easier if Film Gimp
could use the current code).
Last, but not least, it would be very nice if the Film Gimp developers
would not try to increase the distance with the GIMP. For instance,
the following parts of the filmgimp.sourceforge.net web page could be
- The "History" part is slightly incorrect in some parts. Among
others, it states that "The Gimp committee eventually unanimously
voted against Film Gimp." This is of course wrong, since it was
only decided that the merge would be done later. There has always
been some cooperation between the two teams (until recently, maybe).
In addition, there is no such thing as a "GIMP committee" and this
conveys an obviously inappropriate feeling of "us versus them".
- In "The future of Film Gimp", the first goal is: "1. Keep the Film
Gimp Web SourceForge site updated (an unmaintained Web site exists
at film.gimp.org) [Done July 4, 2002]". Why has the site moved to
SourceForge in the first place? When I complained about some
unmaintained pages on www.gimp.org, I was given access to the site
after a while. Now I am maintaining it (until the new design is
ready). Did any of the Film Gimp developers ask if it would be
possible to update film.gimp.org and use that as the main site?
That would avoid much confusion and bring the two projects closer to
- The "Mailing Lists" section states: "Both users and developers are
urged to use the new SourceForge list. The SourceForge Film Gimp
list was created in August 2002 after the Film Gimp mailing list
hosted at UC Berkeley went down for a month with no explanation."
Wouldn't it be more appropriate to say that *all* GIMP mailing lists
have been unavailable for some time because the server had to be
upgraded? As it is written now, it looks like some secret cabal had
tried to silence the Gilm Gimp developers. This is of course not
- That paragraph continues with: "We have no control over the UC
Berkeley list or gimp.org. Likewise, we have no control over
film.gimp.org and the older CVS hosted there." The obvious question
is: why? Did anyone even try? Why is it necessary to criticize the
old site (or gimp.org in general) instead of trying to improve it?
I think that more constructive discussions between the two teams are
really necessary. Widening the gap is definitely not the best
solution. When I see the overlap between the future features that are
planned in both projects, I can only think that continuing on separate
tracks will lead to a huge waste of resources.
P.S.: I cross-posted this to both lists. Feel free to direct your
replies to one or both, as appropriate.
Gimp-developer mailing list