Not to mention the extra work created for localizers if they have to
maintain two forks... it would be like the OpenOffice / LibreOffice mess.
I must admit I understand very little about the technical arguments put
forth in this debate but from the localizer (and to a certain extent
end-user)
My apologies in advance for sounding preachy, but here goes:
GIMP developers need to start paying attention to what potential and
actual GIMP users really want and need from their RGB image editor.
I respectfully suggest the following:
Drop the incredibly paternalistic attitude that the devs
On Wed, Nov 5, 2014 at 4:57 PM, Elle Stone wrote:
Drop the incredibly paternalistic attitude that the devs know better than
the GIMP users what GIMP users really need.
Out of curiosity: if we had that attitude, what was the point of
working with a user experience architect from 2006 to 2013,
On 5 November 2014 13:50, Elle Stone ellest...@ninedegreesbelow.com wrote:
On 11/04/2014 02:31 PM, Jon Nordby wrote:
(apologies for top-posting)
Hi Elle,
The BABL roadmap[1], which was written in response to comments raised by
you (and others),
details a mechanism for working with
On 11/05/2014 09:07 AM, Simon Budig wrote:
Elle Stone (ellest...@ninedegreesbelow.com) wrote:
Why would any sane developer want to write all the new code and have it
exist side by side with equivalent hard-coded sRGB functions?
Why would any sane developer want to fork an existing libary and
On 11/05/2014 07:34 AM, Alexandre Prokoudine wrote:
On Tue, Nov 4, 2014 at 10:27 PM, Elle Stone wrote:
Another advantage to forking babl and GEGL for GIMP is that GIMP's fork of
babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW
(Fourier transforms, http://www.fftw.org/) and
On 5 November 2014 14:50, Elle Stone ellest...@ninedegreesbelow.com wrote:
On 11/05/2014 08:22 AM, Jon Nordby wrote:
What you just described IS side-by-side implementations of
operations. In an ICC profile color-managed application, sRGB is
just another RGB working space. You
