Luis De la Parra Blum schreibt: > hi all, > > On Monday 12 May 2003 15:39, Andrew Sutton wrote: > > 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've bee trying to follow this thread. > some days ago I started a new diagramming code for Umbrello 1 (current > version) in the hope of solving some problems which would be very difficult > to fix in the current code. I started a hopefully shared KCanvas class hierarchy in my kpainter project in KDE CVS. > I took a (quick) look at Karbon, and I really liked the idea behind it, but > could not use it as a base because of the KoPoint Vs. QPoint conflicts, not QPoint has only fixed point / integer coordinates KoPoint and KoRect provide floating point coordinates > so easy integration/dependencies as QCanvas, etc, so I think it'd be great to > move those for now KOffice specifics which are not really KO speciffic to > some kdelib. This was my idea, to. Either that or put it into a separate library which is only dependent on qt and the render libs like libart. > > The other reason I couldnt / didnt want to take Karbon's code as base, is that > it seems to draw everything as a collection of paths ( vectors ). That is, a > box is nothing more that four paths put together in some kind of container... > this of course offers the most flexibility but for umbrello I thought it'd be > easier to have more specialized objects that just paths, so instead of having > a bunch of lines and texts for a UML::Class, I wanted a UMLClassShape which > is specialized on drawing that kind of objects > Agreed. The pure path approach is fine for a general purpose graphics editor, but for application specific graphic objects the way is sub-optimal. > So, to make it short, for those two reasons I could not take Karbon's code as > base, and I wrote everything from scratch, but the code is somewhat inspired > in Karbon's ( Tools, Shapes, Views ) > Do you have code available? Could you please check if it would be possible to work with my code in kdenonbeta/painter/kcanvas (KDE CVS) instead? > I've put two overview-diagrams (as png's) at Umbrello's site, in case someone > is intereseted ( of course you can also have the code. it's under > umbrello/diagram and umbrello/plugins/umlwidgets > > the code is (more or less) well documented, but here a small description so > that you understand the diagrams: > > Diagram : this is the "document" -- not really a document, but it contains / > manages the objects. in the case of Umbrello it's a part of our Document. Check. Its KCanvasModel in my class hierarchy > Note that this is not a visible object, you look at the diagram through the > DiagramView (one or more views can be attaches to a Diagram) > > DiagramView: Renders the Diagram and allows user interaction. It has a ToolBar > with a bunch of "Tools". My KCanvasView is just a QScrollView which manages input events and document rendering. > When it receives events (key, click) it passes the > events to the tools, and they decide what to do with them. The view knows > pretty much nothing about the tools or the shapes it's rendering. The tools I currently have a separate controller class (KCanvasController), which can convert view events to documentation specific "high level" events. I don't really like the current Karbon approach, because this approach doesn't really allow the use of the KDE xmlgui framework, which allow already for dynamic configuration of the GUI (menu, toolbar). I would like to use this xmlgui/kaction framework whenever possible. You get much better KDE integration by using existing frameworks instead of implementing your own. > are loade via ToolBar::addTool( string ), so the tools available for a > diagram could even be loadef from a confing file, and the only shape it knows > it's DiagramElement.. Check. A similar class at my class hierarchy is KCanvasElement. > all other interaction is handled by the tools > > DiagramElement: Base class for all elements in a diagram ( I guess this would > be your VObject) - offers basic functionality like move, setSelected and > "executeDefaultAction" > I haven't worked in this direction, my KCanvasElement is only able to render itself. I am, however fine, to use your definitions into KCanvasElement. > Path: A collection of lines ( or a multi-segment line, if you will ) > - is not really part of the framework, but rather some helper class - should consist of segments, where each segment may either be a line segment or a bezier curve segment. If you need other special segment types, line horizontal lines or arcs, you could check the KVectorPath class in kdenonbeta/kpainter/kpainter. > DiagramWidget: A DiagramElement to which an association can attach itself. > AssociatonWidget: A Path that can attach itself to two DiagramWidgets. Application specific widgets. Should be e.g. part of Umbrello itself. > When > they move, the Association adjusts its ending points or completly move along > with them > > ** the real shapes are implemented in plugins, right now I have > plugin umlwidgets > (replace the word Widget with Shape if you prefere so, UMLWidget->UMLShape ) How about UMLCanvasElement? > > UMLWidget: a DiagramWidget which represents an UML::Element in a diagram. When > it detects that the UML::Element has changed, foreces a recalculation/refresh > of the widget This is real interesting. I know that Canvas like class libraries need back communication (i.e. from the model back to the view). However, I haven't seen until now a real implementtation / interface for that. I would be interested to look at your impl. > > UMLClassWidget: draws a UMLClass on a diagram > UMLAssociaitonWidget: like an associationwidget, but it represents a > UMLAssociation ( the normal AssociationWidget has no UML-meaing, it's only a > visual thing) > (the same for other UML::Elements) > > plugin generic shapes /tools > Shapes like Notes, Boxes, TextLines, etc. > Do you already render the elements, if so, how? > > *********** > All shapes are created by the corresponding Tool, or they can be created by > the diagram through a WidgetFactory if they are droped into it ( for example, > if you want to create a new UML::Class, you use the ClassTool -> when you > click it creates a Class, and then a widget to represent it. But if you drag > an already exisitng UMLClass into the diagrm, the diagram calls > WidgetFactory::createWidget( object ), then the WidgetFactory quries all > loaded plugins to see if one of them can handle that kind of object, and if > yes, the plugin creates the widget and returns it. > Would it be possible to change this sequence so that the standard KAction framework can be used, instead of a custom framework? Regards Dirk _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel