[Uml-devel] Re: karbon/umbrello

Dirk Schönberger dirk.schoenberger at sz-online.de
Tue May 13 14:19:06 UTC 2003


> >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



















More information about the umbrello-devel mailing list