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

[Dirk Schönberger]

> Before we get too much into this discussion I'll move it to
> kde-graphics-devel where more people can read about it :)
>
> On Wednesday 26 January 2005 10:36, you wrote:
>> You talk about adding a QPaintDevice using Cairo, don't you?
>
> No. I'm talking about Qt4, where it is QPaintEngine. QPaintDevice would
> stay basically identical to the x11 one.

Upps, sorry, you are right. Seems I spend too much time in Qt3's painter
in my quest for KPainter ;)

>
>> I would also like to see a QPainter which implements more of the
>> actual Cairo semantics (with implicit paths and full statefull
>> rendering). Basically I would like to add methods like
>
> There are two problems/questions here:
> 1) QPainter is not a derivable class. Meaning QCairoPainter (or whatever
> we'd call it) wouldn't be a class you could just pass to a method
> taking a QPainter.

I have not checked this. At least in Qt3, QPainter was inheritable, but
not in obvious ways...

> 2) Because of 1 that means that we'd be looking into just creating a
> class that abstracts Cairo calls. But the question is: is it really
> easier to do:
> QCairoPainter painter(cairo);
> painter.moveto(20,0);
> painter.relLineTo(40, 40);
> painter.relLineTo(-40,0);
> painter.closePath();
> rather than
> cairo_move_to( cr, 20, 0 );
> cairo_rel_line_to( cr, 40,  40 );
> cairo_rel_line_to( cr, -40, 0 );
> cairo_close_path( cr );
>
> Personally I'm not sure if it is.

I see two problems:

- using raw Cairo seems like a second class citizen, IMHO not comparable
to a proper C++ binding.
- if you use the design as in your sample (QCairoWidget), I see no obvious
way to implement printing, i.e. a non-screen Cairo context (PDF or PS
generator). This could be achieved by separating Painter and PaintDevice
like in Qt QPainter design

> Right now I think that pretty much the best thing we can do is implement
> QCairoEngine and maybe get the handle() return the cairo_t that is
> currently used.
> Then you could mix QPainter/raw Cairo calls or just use one of them.

Sounds like a rather unportable / platform specific solution to me.
Application developers would have to explicitly cast and check if they
have a correct handle / paint device.

My grand plan (which unfortunately currently is on hold because of missing
interest), would be to implement a Cairo like API with multiple backends,
i.e. a ArthurPaintDevice, a LibartPaintDevice, an AggPaintDevice, a
GDIPlusPaintDevice device a.s.o. This is my KPainter project (in
kdenonbeta).

But there seems to be no interest in such a system, at least not currently.

Regards
Dirk