Andrew Sutton schreibt:

> > I think these features are not really needed by applications like Kivio or
> > Umbrello. In these applications the paths are rather application defined
> > and static, don't they?
> 
> who knows. it might be that enhanced path manipulation is very useful in 
> automated layout algorithms. think manipulation of composites, not paths. but 
> i don't know. nobody knows, and i don't think its a reason to completely 
> ignore it.

I didn't say that you should ignore it completely.
IMHO we should use a layered approach.
The lowest layer is something like KPainter / KPaintDevices, which takes
care of the actual rendering using multiple possible backends.
The second level is something like KShape/KCanvasElement/VObjects, static
objects which can render themselves to a KPainter, and can intercept events
like mouse and keyboard events. This I approached in my KCanvas, which is
supposed to be more or less a port of Karbon's V* hierarchy.
The third level is path manipulation, a.k.a. OPAL/C++. A KCanvas element
could have a method like toPath(), fromPath(), where the results can be
used for path manipulation calculations like in OPAL.

> 
> > I think the Visitor pattern implies an accept method for each class of
> > accepted object, as in
> >
> > class Acceptor
> > {
> >   virtual acceptDocument ( Visitor * );
> >   virtual acceptPath ( Visitor * );
> >   virtual acceptPattern ( Visitor * );
> > };
> 
> the way i've always seen it implemented, the visitor implements those methods. 
> the acceptor just knows which of those methods to call on it. i think it 
> works either way, but its more commonly implemented as it is in opal.
> 
ok. agreed. I sometime mix the different roles in a pattern ;)

> > > class Fill;
> > > class SolidFill : public Fill;
> > > class GradientFill : public Fill;
> > > class PatternFill : public Fill;
> > > class BrushFill : public Fill;
> >
> > I agree. The current definition of render modes and their attributes seems
> > to be under-defined in current OPAL ;)
> 
> that's how i felt too :) although, opal does start building on this idea using 
> a LinearGradient and RadialGradient classes.

I will have to check the latest OPAL developments. The latest info I have
is from shortly before OPAL was added to KDE CVS.

> 
> > I thought I had changed this to copy-by-reference in KPainter? SOmehow the
> > Fill and STroke classes are implemented as pure virtual classes without
> > constructors and destructors, which leads to ugly crashes with my C++
> > compiler / at runtime, if I use call-by-value / const references.
> 
> hmm... that sounds like a linker issue. you should be able to pass by value 
> and const reference without any problem whatsoever. it might be that i'm just 
> looking at an older version of the code. i haven't gone back to cvs in some 
> time.

I think I had some problems with class hierarchies with many pure virtual
methods. OTOH I don't have much C++ experience. So if you find ways to make
KPainter more C++ish, fell free to implement it.

Another thing: I found a way to re-implement the whole set of SVG operators
(like relativeMoveTo, relativeLineTo and the like). This again happens by
heavy borrowing, this time from Xr code. What is the current state of the
multiple current running sub-projects about KPainter? Is it ok if I change
the public API of KPainter, and the list of supported primitives? Is there
a timeframe when there will be again a stable set in KDE CVS? My time is
currently rather limited, so it is okay if there is needed more time from
your side....

For an idea about what I would like to achieve, imagine the public methods
from kvectorpath as part of the public KPainter API.

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