On Wed, Jul 28, 2010 at 4:20 PM, Charlie De <charliecoeli@xxxxxxxxx> 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 system. 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 not: 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 remember. 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. David _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
