> From: Lars Clausen <firstname.lastname@example.org>
> Date: 2003/08/08 Fri PM 01:11:20 EDT
> To: email@example.com
> Subject: Re: How many use the diagram tree?
> On 8 Aug 2003, firstname.lastname@example.org wrote:
> >> While preparing to integrate the parenting code with the diagram tree
> >> (making it an actually tree), I ran across a rather obvious bug in using
> >> the diagram tree with groups and undo. Curious that nobody has
> >> mentioned this bug, I would like to hear how many actually use the
> >> diagram tree in their work? And if the diagram tree became more
> >> tree-like (i.e. with groups and parents forming extra branches), would
> >> more people use it?
> > I use it often on a huge UML diagram (~334 classes), mainly to navigate
> > to the class I need to work on. Scrolling at anything smaller than about
> > 30% magnification takes too long.
> Ok, that's good to know. Would it help or hinder you if the groups became
> tree-nodes with their contents as children?
At this point I don't use groups, I think mainly due to my own ignorance (I just haven't thought of anything I could use them for yet). If I did use them, I don't think it would hinder me if they became tree-nodes.
I do find having all the object types (classes, associations, generalizations, etc.) displayed in the same column rather annoying. I have thought about fancy ways to improve this, but I can never get past the acyclic tree widget vs. cyclic diagram relationships problem. At least for the UML sheet, I guess I wouldn't complain if the object types were grouped under tree-nodes.
I will desperately need UML views (The Unified Modeling Language User Guide, p. 468) in the near future. The diagram is already too complex to view in its entirety (it is derived from a horrifying government legacy system).
> > And while I'm on that subject, is there anything I can do to make
> > scrolling at low maginfications faster? I realize I'm not running such a
> > fast machine (900 MHz Via C3 w/ 256M), but Acrobat Reader on the same
> > machine can really zoom around similar diagrams and the same is true of
> > ERwin on my dual 350 MHz P-II, so it seems like it should be possible, at
> > least in theory.
> > I keep meaning to really investigate scrolling performance with gprof
> > (any recommendations other than gprof?), but haven't gotten to it yet.
> If this is with 0.91, then most likely text rendering is to blame.
> Especially when using AA, it has taken a performance hit, I think there
> are some caching opportunities we're missing so far.
I'm building from CVS on Debian unstable. One thing I've noticed that ERwin does is that it gives up on rendering text below a certain magnification threshold because the text would not be legible anyway. I realize this may not be practical for Dia, but it's an idea.
What is "AA"?