[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: QPainter/VPainter API, color models [Re: Explanation on WP vs DTP modes in KWord]
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-12-10 14:18:45
[Download RAW message or body]

> |  > QPainter has a method setColor (QColor), and a method drawBezier()
> |  > (IIRC) What I would like to see is something like setColor (VColor),
> |  > where VColor has an opacity property, which is used for setting
> |  > transparency effects.
> |
> |  As far as I can see QColor uses QRgb for color storage, which in
> |  turn can hold an opacity value (alpha channel) ?
> |

> It seems Xr's XrColor should be ok for the next few years of KDE/KOffice
> development.

I think a VPainter/KPainter should still provide its own colour class. It is
fine if Xr/Xc provide floating point values, this allows for one
transformation less.
What class is currently supported for colour values? I think there exist a
KoColor in koffice libs, VColor for Karbon, others...?

> |  Ah, I see. I guess for extending the API one could indeed create a
> |  new painter class that inherits from QPainter and uses the paint
> |  device command space (everything > QPaintDevice::PdcReservedStop) to
> |  pass the extended functionality to a backend?

> Can you extend Qt in such a way that new color model(s) would be
supported,
> too (64-bit RGBA, 64, 96, 128-bit floating point)?
> I guess you can't do it without breaking backward compatibility.

Yes. Not backward compatible, and not using QColor/QRgb.

> |  My point is that I believe it is much better to re-use the existing
> |  QPainter API and extend it if necessary instead of starting a new
> |  painter API just from scratch. There is much code written using
> |  QPainter, developers are used to it.

> If you use QPainter - you add dependency on Qt.
> Which may be not really necessary for such purpose, as SVG or PostScript
> rendering.

I am not quite sure about this.
I see the following pros in using Qt:

- Qt provide a nice framework and some useable concepts like e.g. QShared or
QPaintDevice, which are not really known outside Qt programming.

Other C++ projects typically invent their own basic programming framework.
The "standard" elements like STL don't provide much high-level concepts,
like e.g. for GUI programming, so it has to be re-implemented case by case.
These frameworks have mostly their own approaches, which makes mixing
several C++ code sources rather complicated.

Regards
Dirk







_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]