From koffice-devel Tue May 27 15:00:08 2003 From: Andrew Sutton Date: Tue, 27 May 2003 15:00:08 +0000 To: koffice-devel Subject: Re: [Uml-devel] Re: karbon/umbrello X-MARC-Message: https://marc.info/?l=koffice-devel&m=105411065306569 > > > But how do you want to implement rendering? > > > > YourVeryOwnRenderingVisitor v.visit( *morph ); the clean way, yes, but i don't think its going to be very efficient for editing applications. for simple generators/exporters this is fine, but for karbon, kivio and umbrello, i don't think that's the best choice. there should be some kind of kpainter integration. i think for editing or vector graphic manipluation applications you need a higher degree of responsiveness in the painting. changes should be immediate. you shouldn't have to re-visit the entire graph just to redraw a single node. > Mabe I misunderstand something, but if you decouple KCanvasElement from the > actual renderer, you have to > make the document classes (KCanvasDocument / VDocument) a more complex > class hierarchy than I thought. > My idea was to make KCanvasDocument itself a rather "intelligent" class, at > least it could handle rendering by calling the appropriate rendering > methods from its canvas elements. Because the document knows enough about > its elements, it could handle things like optimized rendering (drawing only > the parts which are afected from the latest changes. > I your proposal you seem to have to implement this functionality in > children of KCanasDocument, i.e. in KarbonDocument, UmbrelloDocument, > KiioDocument, separately? these aren't issues we should be worried about right now. my primary concern is getting kpainter and opal in line. so i have somewhere to go on my umbrello work. i figure if i can have a good object hierarchy for drawing and a good rendering surface/api, then the canvas will be easy. andy _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel