[Uml-devel] Re: karbon14 and uml

[Andrew Sutton]

okay... error on my part... i'm getting confused between karbon14 and kivio.

the more i'm looking at k14 source, the more excited i'm getting about it - 
and the more i'm thinking about using that as an integral part of u2 - 
specifically the entire drawing framework. it just looks like it fits.

i think some of these might be good ideas. it seems to me that there are 
several applications that could take advantage of a solid drawing framework 
like karbon, consider umbrello, kivio-type apps, svg drawing apps, circuit 
layout apps - alright. anything that might need to dynamically construct 
visual layouts of, well, anything. using k14 as the primary drawing framework 
could probably be done. i think i might like to see a common kde graphics 
framework based on k14.

since each application is different, we propably need to consider some generic 
requirements of each - its actually pretty easy for the graphics stuff.
1. an application might want to display purely graphical information like text 
labels or shapes on a diagram. these have corresponding display properties 
like font or size or line width. these should be accessible via a context 
menu or something. this is pretty much what k14 is doing right now (unless 
i'm just way off). these shapes certainly fall into the primitive/composite 
categories that k14 appears to deal with.
2. an application might want to associate data with a graphical element that 
is being displayed. this is pure uml. graphical elements may be tied to 
corresponding model elements (like the actual UML::Class). if there is an 
underlying data object, the shape (or the object, can't decide right now) 
should provide a dialog that allows users to tweak the settings of the 
object.
3. an application might want to provide alternative graphical representation 
based on information of a data object. uml really, really relies on this for 
subtle (or drastic) variations in notation - consider the <<interface>> 
stereotype for classes. it can make it look like a lollipop. also consider an 
application for network design. a cisco router image might look different 
than a generic linux router image.
4. the shape of an object might be entirely determined by runtime properties 
of the system or parameters. i'm thinking about the guy i share my lab with 
who looks at genetic evolution trees all day long. each tree is determined by 
some iteration through a genetic algorithm to create edges and nodes - but 
its still shown as single shape.

these are pretty basic requirements that other graphic apps might have. it 
looks like k14 already supports most of these - or could support them if an 
application specifically specializes some of the V* classes to provide those 
capabilities. it might be nice to add templates for these capabilities to the 
karbon shape model, but it's not really that important.

my concern here is the usage of kparts within VCanvas and this might just be 
my ignorance on the topic talking because i'm not entirely sure how this 
would work for u2. if we wanted to create a new diagram, could we just create 
a new VCanvas, or do we have to use the k14 kpart to create the VCanvas? it 
seems like the kpart stuff might be safely extracted from any reusable 
library, but that might end up crippling the gui - and we don't want that :) 
rob, i like that you have done a good job separating graphics from data from 
ui, and it think his patterns would persist to other applications as well - 
especially the tools.

i'm actually starting to see certain subsets of u2 as a really complicated 
specialization of k14 - and i don't think i'm wrong seeing this. it might 
takes some time to understand (and maybe a little better documentation of the 
k14 core ;) if u2 follows the same patterns that k14 has and manages to reuse 
the drawing framework, we'll be in good shape (no pun).

so, short of details, i think we've found our drawing framework.

there is however, one concern that i have to express, and i'll do so in a 
separate email, because this is getting long.

andy