From koffice-devel Mon May 12 13:39:22 2003 From: Andrew Sutton Date: Mon, 12 May 2003 13:39:22 +0000 To: koffice-devel Subject: Re: karbon/umbrello X-MARC-Message: https://marc.info/?l=koffice-devel&m=105274686028678 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. > Keep in mind though that not every class that starts with a V will be > appropriate outside karbon. good point. i suppose classses like VSelection will probably have application specific counterparts for the canvas/document component to this lib. > I dont see the MI problem? Probably I am overlooking something, you may > reuse the classes in another way I imagined or so... just from a brief glance it looks like the putting a QObject base on top may be capable of introducing a "circle of death" situation - but i may be reading too much into it. > Well IIRC Lenny wanted to make a core path lib not limited to karbon. So > that would > probably imply not using things like KoRect and other koffice structures. good idea. > They are close, but with a slightly different philosophy. KPainter tries to > stick > to QPainter/QPaintDevice abstraction (so KPainter and QPainter should be > 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. 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. > Phew :) hehehe. > 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. we really have 2 components to saving graphical information. for the most part we don't actually care about saving the static image - just information that can be used to recreate the thing. in otherwords, we're just saving parameters so we'll have to invent our own document model for that stuff. we can, however, save svg within that context to create static documents (that can be scaled for thumbnails or easily exported). > KPainter should be restricted to painting :) I am not very good at coming > up with > names, but vector should probably be in it :) i'm not good with names either, but i think dirk has the room and a good start, if not the best name for what we're thinking ;) > I really hope you have lots of time. Ofcourse I am interested a lot in this > stuff and > willing to help as much as time permits. > Cheers, i have nothing to do for the next... 3 weeks maybe before summer sessions? at least i don't think so. i don't even know if my advisor is going to be around to give me research to do or if my "research" is going to be working on umbrello :) one can dream. assuming i ever get anoncvs to work, i'm going to start hacking the path core (the shapes and such) over to the kpainter/path directory. that sounds like a good place for them. i'm also going to start building signal/slot support for the path core and seeing how/if i can integrate that into the canvas stuff. i don't really want to touch the graphics part... that sounds too hard :) andrew sutton ansutton@kent.edu _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel