[Kde-graphics-devel] Re: [cairo] Qt example in cairo-demo

[dirk.schoenberger at sz-online.de]

> The first one actually isn't true. You really wouldn't be able to change
> the backend. With my initial proposition you'd be able to do that
> (implementing the qpaintengine). With this you couldn't because
> QCairoPainter would be a thin wrapper around Cairo functions.

Correct. QCairoPainter is would be a thin wrapper around Cairo.
My proposed KPainter could provide the same, but with exchangeable backends.

> lineTo, moveTo methods don't exist in QPainter. They are part of
> QPainterPath though.

Yes, they are part of QPainterPath. But QPainterPath is not part of
QPainter's graphical state, i.e. the thing you can save() and restore().
This means you cannot do painter path item compositing, as in

painter.moveto(20,0);
painter.rotate(20);
painter.relLineTo(20 0);
painter.rotate(20);
painter.relLineTo(20,0);
painter.closePath();
painter.save();
painter.fillPath();
painter.restore();
painter.strokePath();

which is possible with KPainter (and QCairoPainter)

> The second also depends on your point of view, because this strategy
> would mean introducing a parallel painter with methods not present in
> the normal QPainter and encompassing most of what QPainterPath does.

I thought the whole idea was to introduce Qt compatible classes which add
wanted functionality. So no difference between stragey 1 and 2 on this
part.

Regards
Dirk