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

List:       koffice-devel
Subject:    Re: Explanation on WP vs DTP modes in KWord (Re: Kde-cvs-digest request for information)
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-12-02 10:03:07
[Download RAW message or body]

On Mon, Dec 02, 2002 at 10:18:45AM +0100, Dirk Schönberger wrote:
> > > The whole world/iewport model I would like to either abandon, or or
> emulate
> > > them with manipulations of the current transformation matrix.
> 
> > Well, if you inherit from QPainter protected there is no point from
> > inheriting from QPainter at all then. The point about inheriting
> > from QPainter is not the implementation (the way it calls cmd on the
> > external paintdevice) but the API.
> 
> Theoretically you are right.
> But I would like to tap the KPrinter functionality in KDE, i.e. being able
> to print to local and non-local printers via print queues. This means that I
> have to provide
> a QPaintDevice.

Haeh? I don't see the relation. Whether to print to a local printer
or a remote printer makes no different in terms of the actual output
to generate. It is merely an IO question, like telling the backend
to store things to a temporary file or into a given buffer. Where's
the relation to the QPainter<>QPaintDevice separation?

> QPaintDevice is most closely coupled to QPainter, both aren't useable
> without the other. In fact I am not quite sure if I even have the chance to
> define new paint deice operators the way I would like to do. Time will tell.

The QPainter<>QPaintDevice API was specifically designed to allow
extending it. See the PDevCmd enum in QPaintDevice and the overall
design of passing commands through the cmd() dispatcher method.

> > Let me give you a nice counter example why a QPainter compatible
> > (derived at best) API is so important IMHO: Imagine there would be a
> > KoPainter that inherits from QPainter. KoDocument could be adjusted
> > to pass a KoPainter to the virtual draw functions that koffice
> > applications have to re-implement. Now imagine you go through the
> > work of implementing a new paintdevice maps the QPainter API to say
> > the SVG rendering model. You do that one, and immediately all
> > koffice applications would get the additional ability to output SVG.
> > Abstraction at its best ;-)
> 
> > The postscript printer in Qt shows that it is possible to map the
> > QPainter API to things like the postscript rendering model.
> 
> The problem is that the QPainter API isn't powerful enough itself. So
> instead of being able to work with the IMHO better Postscript imaging model,
> which is rather
> consistent in itself, you have to work with the stupid API subset from X and
> GDI, which is also known as QPainter. QPainter as API is (at least IMHO)
> inconsistent and ugly. There is a reason the VPainter API was designed the
> way it is.
> You can also render Postscript code using the GDI API. This doesn't mean
> that the resulting Postscript code is useable.
> QPainter is fine for normal windowing work, like GUIs which don't need
> toprint out.
> For serious graphical work, like in a WYSIWIG Office suite, the API is too
> limited.
> Again, just IMHO...

It would be interesting to hear say David's opinion on that, as
someone who has really worked a lot with QPainter.


Simon
_______________________________________________
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]