On Wed, 04 Dec 2002 10:56, Robin Rowe <[EMAIL PROTECTED]> wrote:
> [RaphaŽl Quinet wrote:]
> > I don't know if this list should be updated or not. Maybe when the new
> > site design is ready?
> For an up-to-date GIMP contributor list see the bottom of
> http://filmgimp.sourceforge.net/people/index.html .
As you have probably seen in the recent discussions on the
gimp-developer mailing list, it is not easy to get a correct list of
contributors. ;-) Looking only at the CVS commits or at the authors
of the ChangeLog entries is unfortunately not fair to those who do not
have CVS write access and whose patches are committed by someone else.
Let's see what comes out of the discussion on the gimp-developer
> > Offer an optional MDI interface and menubar on top of the window (bug
> > #7379 and bug #52305).
> Film Gimp already has menus across the top of the window. MDI is coming as
> part of a GUI redesign in 2003.
Yes, this is interesting. I hope that we can cooperate on that and
share some code instead of implementing the same feature twice in
slightly different ways. I have just posted some comments about that
in bug #7379. Feel free to add your own comments there or to discuss
it on one of these lists if you think that we can do some things
> > Implement a macro recorder (bug #51937).
> I'll be implementing that in Q1 2003 for Film Gimp. My approach to macro
> recorder/player design is very different from yours. I'm won't be using
> Scheme, and intend to implement at the GTK+ toolkit level rather than the
> application level. Although our purpose is similar, you need not worry that
> our designs would be any duplication of effort. You may write as much Scheme
> as you like with no concern I would be doing the same. ;-)
The GIMP macro recorder will not be using Scheme either. I think that
you misunderstood how it is supposed to work, but hopefully the
comments that have been added recently to bug #51937 by Hans Breuer
and myself should clarify this issue. Basically, the macro recorder
will be a core function that records the list of PDB calls made by the
tools or plug-ins. Once the list of calls has been recorded, it can
be written as a Python script, or Perl, or Script-Fu (Scheme) or maybe
Tcl, depending on what the user wants. The user will then be able to
edit this script to add customizable parameters to some functions or
to add some comments and documentation before distributing it.
It looks like what you have in mind is not a script recorder, but
something closer to an event recorder. If I understand you correctly,
you plan to record the GTK+ events and play them back later. This is
very similar to what is done by GERD. See bug #82648 for more
details. The advantage of this approach is that it is easier to
implement (especially if you re-use the GERD code) but it is not very
flexible: it would be hard to convert this into a script that can be
called with different parameters (i.e., allowing the user to select
some colors, patterns, fonts, effects, etc.) because these things are
not seen on the GTK level.
> > Merging both does not require the removal of features from either tool.
> GIMP has a reputation for adding more and more features. Film Gimp
> developers are of the opinion that some features are worth removing.
> Film Gimp users and developers are not satisfied with the way Film Gimp
> works now, and are willing to entertain radical change. At the same time,
> Film Gimp has a priority for stability and bug removal that comes ahead of
> features. In these ways Film Gimp is both more radical and more conservative
> than GIMP.
I would say that the GIMP is also more radical and more conservative
than the GIMP. ;-) It just depends on what version you are talking
about. Version 1.2.3 has been released in February and we are still
fixing bugs before the 1.2.4 release, so there is obviously a strong
focus on stability. Personally, I haven't done much on the 1.3.x
branch and I have spent most of my time taking care of Bugzilla and
fixing bugs on the stable branch. The 1.3.x branch is a radical
change from the previous branch because many parts have been
re-written in order to have a cleaner separation between the core and
the GUI. Also, it has been ported to GTK+ 2.0, which should provide a
better stability and portability. You will not find many new
user-visible features in the development branch (new docks, new text
tool, re-organization of some tools) because most of the work is about
cleaning up the code, not adding new features.
> Film Gimp provides an opportunity to accomplish things that wouldn't be done
> in GIMP. However, nothing is lost. We are watching what GIMP and other open
> source projects do, looking for ways to incorporate features that seem
> desirable for Film Gimp. And, perhaps something we implement for Film Gimp
> will later prove useful to other projects.
I don't know how I should understand these statements. After reading
some of the previous mails, it looked like it would be possible to
merge GIMP and Film Gimp again, although not in the near future. But
now, after reading this and some other comments (i.e., suggesting to
re-write Film Gimp in C++), I have the feeling that it will not be
possible. Some users or developers would like Film Gimp to become
more and more independent from the GIMP, without attempting to
converge whenever possible. This is sad. This means that some Film
Gimp developers do not want to contribute anything back to the GIMP.
On the other hand, this means that a lot of work will have to be
invested in re-implementing some GIMP features in Film Gimp. :-(
Gimp-developer mailing list