From koffice-devel Tue May 06 22:12:16 2003 From: =?iso-8859-1?Q?Dirk_Sch=F6nberger?= Date: Tue, 06 May 2003 22:12:16 +0000 To: koffice-devel Subject: Re: karbon/umbrello X-MARC-Message: https://marc.info/?l=koffice-devel&m=105225938419482 > >core is really meant to be a standalone development environment. iirc, there > >was some talk about refactoring karbon's core to provide something like that. > >i'm hoping there is because i don't really feel like trying to make umbrello > >a koffice app just yet. this _is_ my first qt/kde program :) > Yes it was not intended as a shared lib from the beginning. OTOH its > reasonably abstracted > and just oriented towards vector graphics (hence the V :)). > That said, I suppose it could be made a shared lib. To make that work we > would have to define useful, common base classes like VObject, VPath, VText, VGroup etc. > The apps > can then build on this, for instance karbon builds on VPath/VComposite the shapes > VEllipse, VRectangle etc. etc. So I guess first step would be seperating the common (base) classes and the > app specific classes built on top of them. Keep in mind kivio (visio like koffice app) > may want to use the base classes as well. > Maybe next step could be, determining minimum rendering properties > (fills/strokes/gradients/hatches etc.). And after that, maybe exact demands > on the canvas, as I doubt VCanvas currently is optimized enough... I think the rendering model of VPainter (or perhaps KPainter) is a good base for the above mentioned programs. I would like to refactor the V* class hierarchy as part of kpainter, i.e. as shared lib. Basically I woule like to introduce the following base classes KanvasView (based on VCanvas, basically handles view functionality, calls the appropriate render element render methods) KanvasController (handles controller functionality, i.e. translates mouse and keyboard events to commands / actions), handles selections (currently selected KanvasElements). I think this class is currently not really clearly implemented in Karbons V* class hierarchy. KanvasModel, based on VDocument, handles the model functionality. Holds a sequence of KanvasElements, delegates the controller actions to the selected KanvasElements KanvasElement, the elements which are displayed, printed or otherwise rendered. I would like to base KanvasElements on my KPainterElement, i.e. they are rendered using KPainter. Additionally they can handle direct UI events (keyDown, keyUp, mouseUp, mouseDown, mouseMove, or translated calls from the model. I hope that VObject can be used for basic behaviour handling. Child classes of KanvasElements, or VObjects, I agree with VGroup, VText. I am not quite sure about VPath, VEllipse, VRectangle. IMHO there should be implemented application specific classes, like for UML class views. I don't really like a "KanvasUMLClassView inherits from VPath" class hierarchy. Regards Dirk _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel