From koffice-devel Mon May 12 14:24:03 2003 From: "Dirk Schönberger" Date: Mon, 12 May 2003 14:24:03 +0000 To: koffice-devel Subject: Re: karbon/umbrello X-MARC-Message: https://marc.info/?l=koffice-devel&m=105274890431011 Andrew Sutton schreibt: > > okay... i'm starting to get a better picture of our proposed general purpose > vector drawing lib. we have 3 parts to it: > - the painter > - the canvas/document > - the path core > > i'm not entirely sure what goes in the path core. certainly the core framework > for shapes (segments, lines, rectangles). would that also contain classes > such as gradients and fill rules? maybe? i took a look at the opal web page, > but didn't look at the source yet. i guess i should check and see what they > do. At least currently I consider gradients, patterns and fill rules as render related and handle them in kpainter. The path library from Lenny handles things which see paths as geometrical/mathematical beings, instead of just rendering them. This means e.g. things like boolean operations, i.e. creating a result path from two original paths. There is currently some overlapped functionality, because Lenny again created some visual representation in Opal, namely EPS export and OpenGL display. Perhaps things like EPS export in Karbon could be used for exporting/importing functionality, e.g. for the different file formats Karbon supports. This depend upon if the target file format is more suited to an "object based" approach, like e.g. SVG, or more to a "render-like" approach, like Postscript. > > that would > > probably imply not using things like KoRect and other koffice structures. > > good idea. I really like KoRect and KoPoint classes. Basically I see two possibilities: - putting them into kdelibs, renaming them to KRect and KPoint - a compatibility/support lib inside kpainter, which holds often used external classes. This library can be linked static. > > interchangeable), whereas VKoPainter was just something I hacked up > > quickly. > > i don't see why we just can't use KPainter to assume the responsibilities of > both VPainter and VKoPainter. VPainter and VKoPainter are rather legacy, at least if Karbon strts being ported to kpainter. Currently this is not feasible, because karbon is part of koffice, and koffice is in feature/code freeze. > it looks like dirk's KPainter::drawShape method > could be used as the hook for the path core (with KShape being the root > of the path hierarchy). cool. Yes, KShape is supposed to be used for this. You could also create some KShape subclass which contains more kcanvas specific functionality, like e.g. a method boundingBox(), which could be used to determine if a graphical element is "hit" by a mouse position. For this purpose I defined the kcanvaselelement is kpainter/kcanvas. > > Right. I have no idea yet how common VDocument can be for the three apps... > > i'm not actually thinking about a real document (like the document/view > architecture). in this case, the document is internally managed data that > allows the canvas to pass signals to the objects its managing, the canvas > should have weak ownership of its objects (like items in tree/list views). > it's still document/view, but for umbrello, at least, it only represents a > subset of the overall document. > > > BTW load/save as it is now could have some implications. ATM for instance > > karbon VComposite saves/loads svg path data. > I agree with Andrew about the use of documents. Things like SVG import/export could be handled as a visitor, i.e. on the "path library" level. Regards Dirk _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel