Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Future Of The GIMP

Posted by ryuzaki0 on from the bring-out-the-gimp dept.

LinuxNews Team writes: "Sven Neumann and Michael Natterer prepared an RFC about GIMP. We learn that there will be three branches in CVS: 1.2.x branch (stable GIMP), 1.3.x ( devel GIMP but not many new features) and 1.9.x (VERY devel GIMP with whole new structure, GEGL and GCim stuff). Looks like GIMP 1.2.0 is on its way to the users. Check out the RFC."

3 of 119 comments (clear)

  1. A whole new structure for Gimp? by _outcat_ · · Score: 4

    Can you elucidate on this "whole new structure"? Or is not enough about it known yet? Taking a look at the information at

    http://plugins.gimp.org/gimp2/doc_components.html it says:

    libgimpwidgets: core-independent widgets used e.g. to build libui widgets (similar to gimp 1.x's libgimpui)

    but I really cannot stand it when graphics programs change drastically and add "functionality" (on the level of the user interface) that replaces other things that I'm used to. For instance, I really liked PSP3. I really did. (OLD, old stuff we're talking about here.) But I coulddn't stand PSP4.

    I'm reasonably sure the GIMP guys are smart enough not to change things around too drastically, but it's a concern of mine, since I really enjoy working with and playing with The GIMP as it is. I don't want to have to update to a newer form that I really don't like to get the latest neat things.

    Just a concern of mine.

    --
    Angry IT woman in big clompy boots. And talking lint!.
    1. Re:A whole new structure for Gimp? by neutrino · · Score: 5
      The changes that are planned for 2.0 were discussed at Gimpcon this summer. There is a review of the planned new features. For those who are too lazy to read the page, the following is a short rundown:
      • It will use the GEGL, or Generic Graphics Library for pixel manipulatio
      • The rendering pipepline will be tree-based instead of a simple stack
      • The program itself will become much more modular in design -- Model View Controller
      • Plugins and app will communicate via CORBA
      • Generally more flexible -- possible integration with vector-based tools and video editing capabilities
      This is, as you can see, all backend work. Obviously, some changes will have to be made to the interface, but the result will be a vastly more powerful system. If they can successfully implement all of these ideas, then the GIMP would be, in many ways, the most technologically advanced image manipulation program in the world.

      Also, you should see the code as it stands in the 1.x series. It is obvious that the program has evolved to its current state and was not designed to this point.

      --neutrino

      --
      History has the relation to truth that theology has to religion-i.e. none to speak of. - Lazarus Long
  2. Where is GIMP going? by ajs · · Score: 5
    There's some pretty clear problems with the GIMP (to me) that point out one of the greatest weaknesses of open software development. Before I go on, thought I should say that I have contributed to the GIMP, and I think it's a great effort that should keep going.

    Ok, let's say you're developing an OS. You have a clear mandate for what an OS does based on decades of examples.

    On the other hand, if you're developing a photo-manipulation program, you don't have so clear a map. Once you've "done Photoshop", what else should photo-manipulation be? How does that apply to the extant (and future) UNIX(-like) desktops? How important is performance? How important is non-interactive use? How important is any new feature?

    Here's where I think the GIMP should go in the next 2-3 years, but others will disagree....
    • The UI and the photo-editing parts should be separated from eachother. The editing engine should be a library with a well-defined API between it and the UI so that others can slap a GNOME UI on it or a KDE UI or another Gtk+-only UI which uses a single window, etc.
    • All plugins should be re-catagorized and many re-written to fit smoothly into the new catagories. Perl, C, Scheme... it should not matter to the user.
    • Non-interactive use needs an overhaul. One of the most powerful features of the GIMP is being able to script your interaction with it, but most of what people want to do with this will require a single, stateful GIMP that can accept lots of requests at once (call it World Wide GIMP, if you will). This is not really what GIMP was designed for, so most people settle for using a library-based interaction with ImageMagick.
    I know that this list of wants is 180 degrees off of what a lot of people want, but that's sort of my point. It's really hard to figure out what community to serve in the Open Source world....

    I wish the folks at GIMP the best. If I ever have any more spare time, I'll go back to helping them out.