Quoting gimp_user <[EMAIL PROTECTED]>: > ... An MVC architecture and user view customisation tools > would be much more attractive route because it would lay the groundwork for > emulating other tool sets including any future tools competitve to PS. The > challenge for gimp is how to create a long term strategy which may enable it > to flexibly meet future needs that cannot be accurately forecast now. MVC > architecture provides the flexibility required here. So IMHO the next major > version of GIMP requires a total recasting of the code structure in line with > an MVC architecture. The current system architectural is the major stumbling > block for the long term. Until that is solved I do not see GIMP moving away > from the beached whale status as far as its professional high quality image > manipulation future. >
This criticism of GIMP development is the complete opposite of my perception. If anything, the speed of GIMP development has historically been hampered by the development team's focus on abstracting the different components of data, controls, and presentation. Splitting off the GTK and the GDK components as separate libraries certainly took away from GIMP development efforts at the time. The language-agnostic plug-in system was a forerunner in bringing MVC architecture to an application at a level which permitted users to actually redefine the capabilities of the program -- and while 'libgimp' is typically employed by GIMP plug-ins, it is available for any other project to link with as a library entirely separate from the GIMP. The GIMP developers often choose to enhance the abilities of the tools/libraries upon which it relies, rather than opt for a "quick fix" GIMP-specific solution. They have not only followed, but have contributed to internationalization, menu/dialog functioning, even the underlying GObject system of 'glib'. (Any "scorn" of GIMPshop which may have occurred is owing to its developer NOT wanting to work within the framework of the existing "MVC architecture", and NOT wishing to enhance its capabilities; rather than the GIMP developers shunning MVC.) Regarding the 8-bit color model being discussed and a call for the "total recasting of the code structure", that is precisely the decision that was made about six years ago: to factor out the image storage model and abstract the access and manipulation of that storage. The approach chosen was to make such functionality a separate library (GEGL) and continue with the GIMP's development until such time as the library was ready for incorporation into the GIMP code. Certainly the GIMP developers could have kludged the code to incorporate 16-bit or higher bit-depths; and it would not have taken nearly as long to do so. But the solution would be only temporary -- the ultimate necessity to have a separate library would still exist -- and would only apply to the GIMP project. Far from "burnishing its own image", the GIMP developers opt for the best approach and the long-term solutions, often to the cost of short-term expectations. They unselfishly aim to factor their code in a way that benefits all free software projects, not just the GIMP. There should be great pride in doing things "right", even if it may take longer[1]. [1] Personally, I don't think it does take longer. When one looks at the big picture, the short-term solutions ultimately lead to greater amounts of development effort and such projects eventually need to adapt to the more generalized approach or they bog down. For a commercial company (such as Adobe), expending developer resources to produce short-term kludges can be justified if their is compensation from their customer base and if it maintains a marketplace edge over their competitors. In the "real world" of Free Software development, such efforts amount to nothing more than inefficiency in developer resources. _______________________________________________ Gimp-user mailing list [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
