[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-13 15:09:11
[Download RAW message or body]

> The difference between VPath and VComposite is rather complicated.
> Basically Lenny (as author of Karbon) and I (as KPainter author) both
> wanted to introduce Postscript/SVG style vector paths, which are defined by
> the following  features

hmmm... that is rather complicated. the thing is, i don't really know how much 
control we're going to need of the graphics stuff. the selection stuff is 
going to be fairly complex, and if we start talking automated layout, who 
knows how much control we'll need. i'm just not sure. i'd rather not preclude 
the possibility. we'll see what happens. i'm not getting rid of anything 
though :)

i finally figured out why KPainter and VKoPainter seemed so similar... hmm... 
same code ;) some of it anyway.

> Agreed. Besides, I think I made myself not clear enough. I would like to
> use KCanvasElements (which are inherited from KPainterElements) to
> implement the multiple application specific graphic element classes (like
> UMLClassElement). These application specific element classes can be
> composited of KShape classes, KShape is inherited from KRenderElement and
> extends KRenderElement with methods for e.g. bounding box calculation,
> affine transformation at a given point of the perimeter of the element
> (thik things like "render text on or in a shape", hit tests (does the
> coordinate (x,y) hit the shape (bounding box test, perhaps check for
> filled/stroked) a.s.o.

hmmm. i'm still not sure where to go with this stuff. i'm still hesitant to 
put KCanvasElement anywhere near the root of the inheritance hierarchy. it 
still seems wrong to me - but what do i know, i'm a networking guy :)

> It would be one possibility, but at least currently KPaintDevice is used as
> a kind of hack, to be able to get the communication right. If there exists
> more paintdevices and it becomes clear that gstate management is an often
> used functionality, the paintdevices can be refactored to a common base
> class.

i'm already doing that. no sense in leaving it a hack. it turns out to be alot 
cleaner this way.

> > from KCanvas, it won't be too bad. you're right about the painter though.
> > each object does have to render itself. the core VObject stuff WILL be
> > dependent on KPainter (or some Painter), but KPainter should be pretty
> > independent of the VObject details. it certainly is right now :)
>
> I think this should be possible with the KShape / KCanvasElement
> distinction as mentioned above?

yeah. same idea, different classes.

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]