[Uml-devel] u2 user interface

[Andrew Sutton]

On Tuesday 01 April 2003 11:43 am, Carsten Pfeiffer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Tuesday 01 April 2003 17:18, Andrew Sutton wrote:
>
> (Sorry for being unable to follow the discussions lately -- I'm lacking
> time
>
> :( )

certainly understandable - i think all oss developers understand the concept 
of "lacking time". i'm just glad its time and not apathy :)

> If it's only the display, then maybe kdenonbeta/kpainter could become
> interesting. I don't know its goals, but it looks like it's going to
> provide a QPainter based on libart (i.e. with nice antialiasing).
>
> Maybe Dirk can shed some light on it.

interesting. it looks promising, but i've never been really good at getting 
the big picture from reading code. i'm also not much of a Qt developer - i 
haven't done alot of it. to use this, i'm guessing we could start with some 
kind of empty widget for the diagram view (or architecture view), overload 
some paint method and replace the standard QPainer with the KPainter to 
achieve nice anti-aliased graphics?

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

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?

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?

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

4. got any screenshots? i'd like to see good this looks.

carsten, thanks for the pointer. dirk, thanks for the code - it looks like a 
very promising project :)

andy