> as possible. for this, i think KPainter would be an excellent replacement
for
> VKoPainter - they're basically the same thing anyway (built on top of
> libart). we might even be able to package KPainter as the default painter
for
> the object hierarchy - that means there wouldn't need to be any massive
> rewriting for karbon (that i can forsee).

The public interface of KPainter is similar to Painter/VKoPainter by design,
and it is also similar to QPainter.
The idea is to make it some kind of new "official" rendering API.
KPainter has a frontend/backend separation, i.e. the libart based
LibartPaintDevice can be used and is the most advanced paintdeice. There
exist another paintdevice which uses QPainter, but this is less powerful.
As a pro for QPainterPaintDevice, it uses QPainter calls, i.e. you have a
poor-man's version for printing and cross-display rendering.

> question: if people are serious about proceeding with this, where does it
go?
> i'd suggest KPainter, but the name might be a little misleading because
we'd
> be providing alot more than just KPainter (and alot less than Karbon :).
> actually, what would be a good name for this thing?

KPainter (or rather kdenonbeta/kpainter on KDE CVS) is my project for
providing rendering APIs and related stuff.
The directory (and library) kdenonbeta/kpainter/kpainter (libkpainter)
proides the actual KPainter API. I see no problem in creating other
sub-projects and / or libraries.
My private code-name for canvas-like functionality is KCanvas, so I would
like to start a kdenonbeta/kpainter/kcanvas sub-project.
Testcases would be in sub-project kdenonbeta/kpainter/kcanvastest.

Regards
Dirk





_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel