On 08/09/2010 03:42 PM, Rupert Weber wrote:
> while the last patch I posted* to
> is of course outdated already, I think it's time to think about how to
> ever get this included.
As long as you are available to respond to feedback about the patch, it
will be included into 2.8, don't worry. It's just that it might take a
while before anyone gets around to review and test it properly.
> My suggestion:
> (1) Completely drop the xcf enum conversions (xcf-util.*) I introduced.
> They are not needed anymore and, quite frankly, pointless right now.
> This cuts down the patch a bit and means no new files added.
> (2) Separate out the actual conversion routines in gimplibcolor as
> a standalone patch.
> Maybe change the Decompose plug-in to use those, so we at least
> have something to make use of the new conversions.
> (as far as I can tell, the current Decompose Lab functions are
> broken, anyway).
Having conversion routines in a separate patch is reasonable. If
Decompose is broken, a separate patch to fix it would also be good.
> (3) Once gimplibcolor updates are all settled, go about adding new layer
> modes which make use of them.
> (a) decide, which modes. Be conservative, don't clutter the menu
> too much with modes that nobody needs. Once they are out, we
> can't take them back.
CIE LCH based Hue, Saturation, Color and Lightness, right?
> (b) decide how to name them.
I think the displayed names should be like above, and the API names
should have a LCH prefix or suffix. I think the old ones should have
display names with "(compatibility)" appended, and only be shown when an
XCF that uses these modes have been loaded. The API names should remain
> (c) decide how to deal with storing them (XCF version++)
Didn't we already say that the XCF version should be bumped?
My GIMP Blog:
"Automatic tab style and removed tab title bar"
Gimp-developer mailing list