[Uml-devel] Thoughts on Umbrello 1.3

[Luis De la Parra]

hi all,

well, it's been months since last time I posted or contributed anything to 
umbrello, but I'm still alive and try to keep up with the list traffic when I 
can find the time.
first of all: congrats to all of you who have been able to keep working on 
umbrello and have made it such a great tool.

now, about the next version...
> a) improvement of Umbrello 1.2
> b) rewrite of Umbrello 1.2
> c) merge with Umbrello2
> d) something else?

options b/c are really appealing, and are what i _would like to_ do.. but if I 
have learned anything in the last months is that a complete rewrite of a 
program this big is extremely difficult and a try to do so has actually more 
chances to fail than to suceed.

there is one thing that I think no one doubts here though: the internals of 
umbrello are a mess. 
unfortunately paul's original design was not the best one. I'm a sure he had 
his reasons ( he had to turn in the program as a final project ) and so he 
choosed a design that was relativly simple and fast to implement, but then 
people started adding features and doing "quick/dirty" fixes to the codebase 
just to get the new features running. the problem now is that each time 
someone changes something, 10 things seem to break somewhere else.

so, in conclusion, we do need a full re-write, but I'm afraid trying to do all 
at once would require more time/energy than most of us have.

one of the principles of refactoring is actually never to do changes that are 
too big at once, and that is exactly what I propose.
we should try to integrate the omf/umbrello2/whatever into umbrello and then 
replace small parts at a time.
maybe start with a few of the umlobjects, then change the diagrams (one at a 
time), then rewrite the diagram code, then maybe kpartify, etc..
the problem with this is that it is more work, since you have to sometimes 
code things that you are going to throw away in a few weeks anyway (adaption 
layers) but I still think this is better than having an app which won't even 
build for several months.

>
> Automatic tests as suggested in
> http://bugs.kde.org/show_bug.cgi?id=70256 would be useful.

test is really important. I must confess I'm not used to it, but in the long 
term it'd be worth it. maybe we can integrate boost's test framework and some 
tests in the repository.

> QCanvas works well for us as a canvas but anti-aliasing and SVG export
> would be nice.  I suspect it's still the best going at the moment.

QCanvas is easy, but it has its limitations ( you get zoom "for free", but 
it's pretty much unusable because the text gets so distorted(?) )
a svg-widget would be nice, but at least ksvg is not there yet ( I did some 
playing with it 2 months ago, and although it renders static svg files just 
fine, it is not yet usable as a component)
I think there is a gtk-based widget which seems to be more developed, but it 
would add a _big_ dependency, so it's probably not worth it

ok.that was just my 2 cents contribution....

saludos
luis