From koffice-devel  Mon Jul 17 22:47:42 2006
From: Casper Boemann <cbr () boemann ! dk>
Date: Mon, 17 Jul 2006 22:47:42 +0000
To: koffice-devel
Subject: Colormanagement upgrade path
Message-Id: <200607180047.42657.cbr () boemann ! dk>
X-MARC-Message: https://marc.info/?l=koffice-devel&m=115317670703720

Hi

This mail describes how to get colormanagement into [insert your KOffice app 
her].

The intention is to do the upgrade as smoothly as possibly, but in the end the 
goal is to replace every QColor in your data objects with KoColor. When 
drawing your data object to screen you just call KoColor::toQColor() to get a 
QColor you can draw on screen.

That was the output. The input of color comes from two sources:
  - the user (via widgets)
  - files (mostly as simple (nondescript) RGB triplet)

For user input we have the KoUniColorChooser which is a widget that allows 
input in HSV, RGB, CMYK and Lab. The KoUniColorDialog encapsulates this 
widget in a dialog with Ok and Cancel buttons if that is what you prefer.

For applications such as KSpread which in all fairness don't have huge color 
demands there will be the KoColorSwatch which will provide a palette/swatch of 
preset colors. It will also have the possibllity of a custom color that 
brings up the KoUniColorDialog.

Input from files is a bit harder. Ideally we would like to save the color in 
any colorspace and get it back like that (hopefully David will be able to get 
this into ODF somehow). Still we need to be able to accept input of simple 
(nondescript) RGB triplet because that is how color is currently stored and 
how other apps do it.

The constructor for this is:
    KoColor(const QColor & color, KoColorSpace * colorSpace);

which requires a colorSpace which you should get from a 
KoColorSpaceFactoryRegistry by calling:
    KoColorSpaceFactoryRegistry::instance()->getRGB8();

The registry is a singleton.

But upgrading all of your dataobjects to KoColor in one go might be a huge 
task, so what I propose is to do the following:

If you application has a notion of a current color do a double implementation 
while transitioning so that the rest of your application can either get a 
KoColor or a QColor. Then when all is done you can remove the QColor version 
completely.

Setting the current color should use the widgets described above. This should 
set the KoColor version of the current color and then use toQColor() to set 
the QColor version of the current color.

If your application only sets colors at specific locations (such as the 
property of an object) then simply replace the widget at that point and use 
the returned KoColor to set your data object. 

Either use that opputunity to convert that dataobject to KoColor or use 
toQColor() until you convert the dataobject later. In the latter case I 
recommend making a global function:
  QColor convertToQColor(KoColor &)
which you can later remove causing compile errors if it is still in use.

-- 
best regards / venlig hilsen
Casper Boemann
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel