From koffice-devel Tue May 13 15:09:11 2003 From: Andrew Sutton Date: Tue, 13 May 2003 15:09:11 +0000 To: koffice-devel Subject: Re: [Uml-devel] Re: karbon/umbrello X-MARC-Message: https://marc.info/?l=koffice-devel&m=105283911418371 > 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