Hi,
I want to report some feedback on the graph layout of byecycle.
Although graphical visualization of dependencies is a great idea, its
implementation is currently not satisfactory.
As you can see in the graph_layout.png file (see the "files" section
in the group), even if I give the dependency tab a lot of space, only
a very small amount of it is used, and the resulting graph is so
crowded, that it cannot be read usefully.
Moreover, sometimes the algorithm does not arrange things in the
"best" way. For instance, the package org.xml.sax is only referenced
by the SAXErrorHandlerImpl class, and it could be put under it but
still close to it, rather than at the very bottom of the graph,
letting its arrow make the graph unreadable. The solution to this
problem could be a "perfect" algorithm ;-), in the meantime, it would
be ok if I could move the package by dragging it, and the algorithm
starts from the position I suggest.
BTW, I strongly agree with Jeff Winkler, it is a waste of time
watching the graph adjusting slowly, if it's the only task I'm
supposed to complete for my boss. Still, ByeCycle is an official
excuse for a coffee break ;-)
I have actually experimented a little with layout in byecycle, with a genetic algorithm. It sort-of works, in my first weird variant. My second, more "proper" fares much worse. Neither is better than byecycle currently is, I would say. I suspect one problem lies in how the stressmeter is tuned: I find if I up the force for the "dependency-down" force, I get better results.
On Wed, May 14, 2008 at 5:21 PM, alfredo.pironti <alfredo.piro...@gmail.com> wrote:
> Hi, > I want to report some feedback on the graph layout of byecycle. > Although graphical visualization of dependencies is a great idea, its > implementation is currently not satisfactory.
> As you can see in the graph_layout.png file (see the "files" section > in the group), even if I give the dependency tab a lot of space, only > a very small amount of it is used, and the resulting graph is so > crowded, that it cannot be read usefully.
> Moreover, sometimes the algorithm does not arrange things in the > "best" way. For instance, the package org.xml.sax is only referenced > by the SAXErrorHandlerImpl class, and it could be put under it but > still close to it, rather than at the very bottom of the graph, > letting its arrow make the graph unreadable. The solution to this > problem could be a "perfect" algorithm ;-), in the meantime, it would > be ok if I could move the package by dragging it, and the algorithm > starts from the position I suggest.
> BTW, I strongly agree with Jeff Winkler, it is a waste of time > watching the graph adjusting slowly, if it's the only task I'm > supposed to complete for my boss. Still, ByeCycle is an official > excuse for a coffee break ;-)
