memory kicks in ... On Mon, May 17, 2004 at 09:08:51PM +0200, Sven Neumann wrote: > Carol Spears <[EMAIL PROTECTED]> writes: > > this is not the case with gimp-2.1 and that nice list. can someone > > remind me of the logic of this (i assume) temporary condition? the > > developers i came to respect went out of their way to avoid this. > > gimp-2.1, which is supposed to become gimp-2.2, will be compatible > with gimp-2.0 so there is no point in having the two versions > installed side-by-side. When gimp-2.2 is ready it will happily replace > gimp-2.0 and plug-ins compiled for gimp-2.0 will continue to work. > > That's the reason that gimp-2.1 cannot be installed into the same > prefix as gimp-2.0. It's supposed to replace it. Currently there's the > temporary condition that gimp-2.1 installs quite some things into > directories versioned as 2.1. This is supposed to be changed back to > 2.0 when gimp-2.2 is ready. > thank you for the explanation.
my memory now is that there were so many things (plug-ins) that would need name changes for the new previews and similar changes. if this memory is correct, is this a simple grep something and change it to something else operation? i am always on the look out for a cool use for something like that "removecruft" thing someone wrote way back when. is this one of those cases? perhaps not "removecruft" but "updatepreviewability" causing the temporary part of your explanation to be a wonderfully short case of temporary; i have seen some cool things throughout my watching gimp development for all these years and years.... carol _______________________________________________ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
