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

List:       koffice-devel
Subject:    Re: [Uml-devel] Re: karbon/umbrello
From:       "Dirk Schönberger" <dirk.schoenberger () sz-online ! de>
Date:       2003-05-21 17:55:35
[Download RAW message or body]

Andrew Sutton schreibt:

 
> if this is all going to be c++, we should pull dirk in and use KPainter as the 
> main painter/paintdevice lib. i see two major differences in paradigm: 
> opal/karbon uses objects to describe paths. KPainter relies on the *To() 
> methods to establish paths. these are actually fairly reconcilable. the other 
> main differences come from the stroke, pattern, fill, gradient and color 
> classes. these should receive alot of attention so we can establish a set of 
> standard interfaces for KDE.

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?
For stroke, pattern, fill and the like I agree.

> 
> there seems to be a lack of documentation in the ruby stuff :) i'm not sure 
> where the name "Morph" comes from... it seems an odd name for a base class 
> (although maybe a little better than Object).

According to a discussion I had with Lenny a "Morph" is taken from the
Smalltalk/Squeak class library (http://www.squeak.org). The name was taken
because Ruby has not good name space support, and the name "Object" was
already taken, and to general...
Class-name-implicit namespaces, like in the V* class hierarchy, doesn't
seem to be part of the Ruby naming style.

> 
> if i was to complain about api's, i guess i'd have the following complaint: 
> better separation of concerns. i think i'd like to see some of the 
> functionality abstracted out of the base class a little better - specifically 
> visitor acceptance.
> 
> class Acceptor
> { virtual accept( Visitor * ); };
> class Morph : public Acceptor
> { ... };

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

IMHO it is not possible to override a method multiple times in C++, like in

class DocumentAcceptor
{ 
  virtual accept ( Visitor * ); 
};

class PathAcceptor
{ 
  virtual accept ( Visitor * ); 
};

class PatternAcceptor
{ 
  virtual accept ( Visitor * ); 
};

class Morph : public DocumentAcceptor, PathAcceptor, PatternAccepttor
{
};

> 
> also, i liked dirk's ideas on some of the core painting objects: specifically, 
> the way he deals with patterns and the like... (from above).
> 
> 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 ;)

> the same goes for strokes and patterns too. i think that's a pretty good 
> abstraction. the only problem i might have with this is the use of 
> copy-by-value painting objects. using this design.

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.

Regards
Dirk


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