[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Colormanagement upgrade path
From: Casper Boemann <cbr () boemann ! dk>
Date: 2006-07-17 22:47:42
Message-ID: 200607180047.42657.cbr () boemann ! dk
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic