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

List:       koffice-devel
Subject:    Re: [Uml-devel] Re: karbon/umbrello
From:       Andrew Sutton <asutton () mcs ! kent ! edu>
Date:       2003-05-21 18:41:16
[Download RAW message or body]

> Karbon is supposed to a general editor, where the paths are supposed to be
> editable (think editing of nodes, creating and deleting from nodes and
> such)
> OPAL taks the path management and enhances it, so that it should be
> possible to implement algorithms which work over paths.
>
> 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 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.

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

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