From koffice-devel Tue May 13 21:14:36 2003 From: =?iso-8859-1?Q?Dirk_Sch=F6nberger?= Date: Tue, 13 May 2003 21:14:36 +0000 To: koffice-devel Subject: Re: [Uml-devel] Re: karbon/umbrello X-MARC-Message: https://marc.info/?l=koffice-devel&m=105286080113094 > >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. > I dont really care if you want to put it in a "libgvgraphics" which only > depends on qt and libart, or if you want to put those classes into > libkdebase.. the only thing I think it's important, is that it should be > easyly available. I would not care linking against libkdebase, because I do > it anyways, but I would not want to link against libKOffice just for that. I think this will be accomplished in the near future. > >Do you have code available? > yop. > The "base" diagram framework has been in umbrello's cvs for some days now, > and last night I checked in the uml-shapes plugin. > you need to checkout/update kdesdk/umbrello I will check it out. > >My KCanvasView is just a QScrollView which manages input events and > >document rendering. > my DiagramView is just a QCanvasView which manages input events... which is > not much more than a QScrollView which manages document rendering.. so it's > pretty close to your's > Diagram is a QCanvas. If you use QCanvas your are limited by the rendering model of QPainter. My idea is to provide a slightly more powerful rendering model, which is powerful enough to render Postscript and SVG like graphics. This includes semi-transparent graphics and antialiased rendering. Please see http://www.xs4all.nl/~rwlbuis/karbon/pics/kpainterchartview.png http://www.xs4all.nl/~rwlbuis/karbon/pics/kpaintertestview.png for examples of the new rendering model. In kpainterchartview.png the upper chart is rendered using defualt QPainter, while the lower part is rendered using KPainter (and a libart based paint device) The negative part on using KPainter is that you have to re-implement QCanvas. > >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. > I'm not sure if I understood you here... > the events in my DiagramView are all like this: I will have to look KAction more closely, bus as far as I understood, you implement KAction classes and register them to some manager. The actions are rendered, e.g. to tool bar buttons and menu entries, using a XML definition file. If an action is executed, a method, e.g. in a controller class, is called. This means, you implement multple actions and centralize the event handling in one (or more) controller classes. Theses controller classes should work on the underlying document. If you implement a tool-based design, like e.g. in current KAction, it becomes rather difficult to use the KAction framework. > > it's DiagramElement.. > >Check. A similar class at my class hierarchy is KCanvasElement. > yes. DiagramElement is a QCanvasPolygonalItem This makes it rather difficult to implement Karbon style vector paths (like Karbon VComposite / Karbon VPath). If you really want to render filled vector paths, you could look e.g. in KPDF or the QPainterPaintDevice in KPainter. The code is not exactly trivial. > >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. > my DiagramElement can't render itself ( it's abstract ) but it provides the > hook for sublcasses to draw themselves. Sorry, I meant this, too. > well... my Path is a DiagramElemnt which has a list of PathSegments. > the PathSegments are lines ( I didnt think of beziers because I didnt need > them, but of course a PathSegment could be that as well ) This sound more easy than it is, trust me ;) > >How about UMLCanvasElement? > what about it? > I have no UMLCanvasElement in my code. Sorry, jst a naming proposal (instead of UMLWidget / UMLShape...) > I dont know if I understand you here.... > the process is as follows: > the application calls > loadPlugin( string ), giving as parameter "umlshapes" and "cool_umlshapes" > the plugin framework calls > Plugin::initialize( ) > and in the initialize implementation, both plugins call > WidgetFactory::registerWidgetSet( this ); > ToolFactory::registerWidgetSet( this ); I haven't looked further, but I think that instead of registering a at a widget factory and a tool factory, you should register widgets/shapes, controllers and KActions at a action manager. The action manager is part of the KDE libs, and most applications use this framework already. Regards Dirk _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel