On Wed, Jul 28, 2010 at 4:20 PM, Charlie De <charlieco...@yahoo.com> wrote:
>> Since we released stable  versions with this broken behavior we now have
>> to maintain backward  compatibility to it. It is considered very
>> important that you can open your  old XCF files in a new version of GIMP
>> and get the same result as in the  version you created them in.
> I suggest that implementing the improved functionality is of much higher
> priority than backwards compatibility with the old.  Particularly in a project
> such as GIMP, where development resources are as precious as they are.

> You can tackle this with a marketing "thought experiment": if you were to ask 
> a
> group of GIMP users what they would prefer, speedy fixing of broken features, 
> or
> insistence on backwards compatibility, which would the majority vote for?

This is an erroneous dichotomy, because a failure to preserve
backwards compatibility is itself a 'broken feature'
GIMP is the definitive loader of XCFs. Any other format, it is nice if
it supports perfectly, but hardly needed. Its own format, it MUST
support perfectly, however it achieves that.
It must load any sane XCF in such a way to produce just the same
result as it ever did.
Otherwise you create a situation where you are silently changing the
meaning of people's XCF images. It's like you changed the symbol '2'
to mean 'twice twice twice one' (that is, 8); People will still expect
2+2 to equal 4, not 16. Some people will notice that their maths comes
out weird, some people won't. Regardless, it's just not reasonable to
indirectly change the meaning of people's creations in this way.

> Besides, the appropriate and established way of addressing backward
> compatibility is through the handling of old files, not by refusing to 
> implement
> improvements.  Reading some of the discussions among the GIMP development team
> in relation to the issue of broken Color transfer mode was the first time I
> encountered the argument that it was preferrable to keep the broken
> functionality over fixing it, because a user might want to keep old rendering 
> in
> the new version.  What a nonsensical argument!

Implausible, rather.

Almost all of the improvements we could look at would be much more
readily coded and tested with solid GEGL integration. This is
something that we do not currently have, it's more like a
well-constructed Frankenstein, with some systems having an option to
use GEGL, others not, and none with GEGL as the default/only rendering
Really solid and complete GEGL integration, IMO, would be far more of
an asset to GIMP than any one other user-visible improvement, because
of it's major synergistic effect on our ability to quickly write and
test new image manipulation operations / combinations of operations.

Old file handling only goes so far: XCF is not only GIMP's fileformat,
but represents the way GIMP conceptualizes the notion of a complex
image. When basic concepts change, it is normal to not be able to map
the old information 100% accurately onto the new format.
(that time is not yet, though.)

> Has there been a single user outside the dev team who expressed this view?
> At this stage I'd prefer to avoid the argument and let the team focus on the
> positive task of bringing out the next version.  However, there will be bugs 
> in
> new stable releases, in 2.8, 2.10 and beyond.  So the argument of how those 
> bugs
> are to be dealt with and what priority backward compatibility is to have will
> not go away.  We might as well tackle it as we go along instead of delaying 
> it.

My understanding is that breaking compatibility is on the table for
3.0, *and no earlier*.  Because of the change of paradigm between
classic GIMP and GEGL-based GIMP,  GIMP 3 XCFs would naturally be
quite a different beast to GIMP 2 XCFs. This makes it a natural point
to break compatibility at, since users will need to learn to do quite
some things differently anyway. Before then, GIMP won't work
differently enough to flag to the users that hey, things may not work
quite the same as you're used to.
If GIMP 2 can load GIMP 2 XCFs 'perfectly', and GIMP 3 loads GIMP 3
XCFs 'perfectly', then this is straightforward from a user point of
view, no? OTOH if we change in the middle of a major version, it is
GIMP 2 XCFs would be loadable by, say GIMP <=2.8, and GIMP >2.8 would
load GIMP 3 XCFs. That's unfriendly behaviour and much harder to

tl;dr version: There are good user-friendliness and
programmer-efficiency reasons for leaving compatibility breakage until
GIMP 3, and you have not presented any particularly compelling reasons
for breaking compatibility earlier

Have a nice day.

Gimp-developer mailing list

Reply via email to