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

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.

> 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.
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.
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.

Zack

--
If money is the root of all evil, why do churches want it so badly?

[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

[Mosfet-2]

Heh, and I am going to do a libart-based painter class for MImage as I already
mentioned on this list... We are certainly not going to be lacking for paint
classes and/or destination devices ;-)

BTW, I finished porting Imlib2 dithering as well as the KDE Floyd-Steinberg
dithering. It can dither to 2 (bitmap), 4, 16, 32, 64, 128, or 256 colors. If
anyone is interested I can post screenshots.

On Wednesday 26 January 2005 01:44 pm, Dirk Sch?nberger wrote:
> > 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.
>
...snip...
>
> Regards
> Dirk
>
>
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

[Richard Moore-3]

On Wed, 26 Jan 2005 11:17:09 -0500, Zack Rusin <zack@...> wrote:

> 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 );

One big difference is that with the first example I can switch
back-ends with a single line of code. This is a big deal when you try
to do something you hadn't thought of when you wrote the code. The
first example is also easier to read if you're used to working with Qt
style APIs as you don't need to 'change gear'.

Rich.

On Wednesday 26 January 2005 18:43, Richard Moore wrote:

> On Wed, 26 Jan 2005 11:17:09 -0500, Zack Rusin <zack@...> wrote:
> > 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 );
>
> One big difference is that with the first example I can switch
> back-ends with a single line of code. This is a big deal when you try
> to do something you hadn't thought of when you wrote the code. The
> first example is also easier to read if you're used to working with
> Qt style APIs as you don't need to 'change gear'.

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.
lineTo, moveTo methods don't exist in QPainter. They are part of
QPainterPath though.
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.

Zack

--
I considered atheism but there weren't enough holidays.