On Wed, 04 Dec 2002 10:56, Robin Rowe <rower@xxxxxxxxxxxxxxx> 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 mailing list... > > 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 together. > > 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. :-( -Raphaël
