[Gimp-user] Bit-depth Processing

[saulgoode at flashingtwelve.brickfilms.com]

Quoting gimp_user <david at atf4.com>:
> ...                  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.