[Uml-devel] u2 user interface

[Dirk Schönberger]

Hi,

> dirk, since you're copied on this i wonder if you'd be able to answer 
> some questions on usability?

I will try to answer some questions.

> 1. i've noticed some checkin comments mentioning SVG stuff, but i'm not 
> entirely sure how it fits in. can we construct classes that use standard > SVG elements (either XML or SVG object model objects) to tell the 
> painter what to paint? does that tie into the KShape class somehow?

Hmm, KShape is part of the KPainter API and simply define a element to
render. It can be used to extend the KPainter API with custom shapes.
At least currently it is limited to rendering, I am not quite sure how to
implement interactive features.

SVG rendering is a sub-project of KPainter and tries to provide a framework
which can be used for rendering. SVG files are parsed by the default Qt XML
parser, and it is build a im-memory represenation of the SVG render tree.
SVG documents can contain references to other elements in the tree, so a
pure event based (like SAX) SVG rendering doesn't seem feasible.
AT least currently my SVG renderer is limited to static rendering. Dynamic
rendering (scripting, animations) could be added later, but this may lead
to API changes.
My current projects are to provide SVG icon rendering for KDE, and a
generic SVG qimageIO handler for loading SVG documents (i.e. each Qt/KDE
app can display SVG documents)

> 2. the app needs to be able to respond to events on the diagram - 
> specifically clicking on something or maybe even mousing over an 
> element. i don't really know alot about Qt, but i thought that this 
> might be a capability of some kind. is there support to send a signal to > KShape's when an event occurs on or over the drawn object? if not, could > it be added?

Current KPainter / KShape is not interactive, it is only used for
rendering. If you need interactive work, I suppose there should be work
done for a KPainter based canvas (conceptionally similar to QCanvas, but
using KPainter as output device).
koffice/karbon contains code which could be used as a basis for such a
project. Please contact Rob Buis (rwlbuis at xs4all.nl) if there is interest.

> 3. is there any information on paintdevice manipulation performance? 
> specifically, we'd probably like to be able to drag shapes around a 
> diagram - typical diagram editing stuff. if we're using SVG data or 
> objects to construct the shape, how much of a performance hit could we 
> take? what if we were manually rendering each shape (using KPainter::* 
> methods)?

I haven't done actual tests for interactive work, but koffice/karbon
provides similar featues. Interactive work is more or less possible.
Another idea would be to use another KPainter backend. I started work on a
QPainter based backend, ie. it creates normal QPainter calls, instead of
rendering to an image using libart. This could lead to better performance,
with the cost of less rendering quality (e.g. no antialising) 
My QPainter based paint device extends the code in Karbon by providing full
rendering support. Karbon code only supports line rendering (wireframe
modus)
Another possibility would be a paint device based on the XRENDER extension
(or the Xr/Xc library, see www.xsvg.org for details). This is work in
progress, which would provide hardware accelerated antialiased rendering of
a Postscript-like rendering model.

> 4. got any screenshots? i'd like to see good this looks.
http://www.xs4all.nl/~rwlbuis/karbon/pics/kpainterchartview.png

shows mixed KPainter and QPainter content with a chart view. The lower
chart is rendered using KPainter and a LibartPaintDevice

http://www.xs4all.nl/~rwlbuis/karbon/pics/kpaintertestview.png

shows some old and buggy elements using KPainter and LibartPaintDevice. The
labels are rendered using QPainter, because KPainter currently has no text
rendering support.

Regards
Dirk