Identifying color models (and channels, etc.) - an rfth

[Boudewijn Rempt]

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 
have:

* 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 
  internally. 

* 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 
descriptive strings.

So -- this is a request for thoughts... What would be best.

-- 
Boudewijn Rempt | "Geef mij maar zuurtjes."
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20041223/6ad8987e/attachment.pgp