[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 16:04:45
[Download RAW message or body]

> It uses a lot of the same ideas, some slightly different. BTW you dont have
> to restrict yourself to the ruby version, I put my stuff in cplusplus/.
> I suppose you are more "dependent" on kpainter and some canvas, that may be
> more important to umbrello2 right now. Still, I think OPAL should be used
> as a base for karbon/umrello2/kivio, so now is your chance to have a think
> about the Child/Parent/Morph structure and gripes about the API used :-)
> Cheers,

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.

i must not have gotten the right version, because there wasn't a c++ version. 
otherwise, i suppose i'd need cvs access or something.

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

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
{ ... };

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;

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.

how do i get a copy of the version that you're talking about?

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]