Identifying color models (and channels, etc.) - an rfth
boud at valdyas.org
Thu Dec 23 13:50:54 CET 2004
We've now got four ways of identifying color strategies, and I fear we
should add a fifth, but I'm not sure of the best of doing this. We currently
* Constants in kis_global.h -- the old, fixed way. Has to stay to remain if we
want to be backwards compatible -- not sure if that's worth it, though,
given our enormous user base.
* name -- this is what we currently use in files, user interface and
* cmType -- this is what lcms uses. We need this to create transforms, but we
probably won't need it outside the color strategies.
* icColorSpaceSignature -- this is what identifies profiles as suitable for a
certian colorspace type.
Now the big problem is with name -- and that holds for almost everything
that's stored in KisGenericRegistry or one of its descendants. We use the
name both in the UI and internally. And that's bad, because it means we
cannot i18n the names, and we really want that.
My first idea would be to expand KisGenericRegistry with an id->item map,
and duplicate all methods (getByID, getByName, listNames, listIDs, etc.), but
I'm not sure whether that's the best solution.
We might make the id not a string but an int, but then we need some way of
distributing id's to plugin writers, which we wouldn't have to do with more
So -- this is a request for thoughts... What would be best.
Boudewijn Rempt | "Geef mij maar zuurtjes."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20041223/6ad8987e/attachment.pgp
More information about the kimageshop