Dependency chart becomes unreadable with >12 dependencies

What about adding a "+"/zoom button? The first time I saw an unreadable dependency tree I intuitively looked for a zoom button...

Setting to "High". This makes many of our dependency charts useless, which vastly reduces the utility of the blueprint manager.

This is still annoying. Somehow, I'm not sure having it assigned to Steve is sane.

Still no new work on this.
Can anything be done in the near future?

The Dependency Tree is a wonderfull fool, but if no one can "see" it there's no need for it!

Please allow it to grow a bit.

This bug needs to be fixed.
The dependency chart is useless as it is. Any sane project would have a number of dependencies that can't be displayed by the current tree viewer.

Agreed. So the best way forward is to figure out how to lay out the graph when the number of dependencies is that large.

I think there are some ways to tweak the dot layout policy to get graphs in different shapes when you get over a certain number of deps.

Another idea is to have the mini dependency tree link to a separate, complete view that can scroll out and for bonus points display that using AJAX.

Any other good ideas?

As kiko says, we should look into what dot offers us today, and possibly tweak the page layout a bit so we can use the full width of that part of the screen.
A combination of those two will hopefully be enough until we have the infrastructure for 3.0 in place, and we can start using magic.

Some things you could try adjusting are:

http://graphviz.org/doc/info/attrs.html#d:ratio
 - You can use this to set the desired aspect ratio of the graph.

http://graphviz.org/doc/info/attrs.html#d:size
http://graphviz.org/doc/info/attrs.html#d:dpi
 - these two might help you produce output at a particular pixel size.

Some wizzy thing that had a JS google maps-like way of viewing a graph would also be handy for loggerhead......

The ratio option doesn't seem to do much useful w.r.t. actual layout. I notice that the graph is being passed through "unflatten -l 2", which accounts for the two-level appearance of the dependencies. Increasing the "2" to something higher might give a more square output.

Another thing you could try is one of the other graphviz layout programs instead of dot. Neato might give reasonable results with mode=major.

On Wed, Sep 3, 2008 at 5:10 AM, James Henstridge <
<email address hidden>> wrote:
> The ratio option doesn't seem to do much useful w.r.t. actual layout. I
> notice that the graph is being passed through "unflatten -l 2", which
> accounts for the two-level appearance of the dependencies. Increasing
> the "2" to something higher might give a more square output.
>
> Another thing you could try is one of the other graphviz layout programs
> instead of dot. Neato might give reasonable results with mode=major.
>
> --
> Dependency chart becomes unreadable with >12 dependencies
> https://bugs.launchpad.net/bugs/66344
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Launchpad Blueprint Tracker: Confirmed
>
> Bug description:
> The dependency chart is unreadable for any specification that has more
than about a dozen dependencies. For example, <
https://features.launchpad.net/products/launchpad-foundations/+spec/1.0-web-interface
>.
>
> This could be fixed by making the dependency levels run vertically, rather
than horizontally. This would work better because specification names are
shorter than they are wide, so they could be packed more closely together.
>

How about using a vertical view? It could be even done in simple HTML

current_task
+- dep1
+- dep2
| +- dep2-a
| +- dep2-b
| +- dep2-b-I
+- dep3

or

+-dep3
| +- dep2-b-I
| +- dep2-b
| +- dep2-a
+- dep2
+- dep1
current_task

Giuseppe

Committed a partial fix for this in revision 6962.
Showing between 20 and 30 dependencies should look "acceptable".

The long term solution will be using Ajax magic, which we will have soon-ish.

On Sat, Sep 06, 2008 at 03:27:25AM -0000, Martin Albisetti wrote:
> Committed a partial fix for this in revision 6962.
> Showing between 20 and 30 dependencies should look "acceptable".

An additional improvement would be getting rid of the actions portlet
for that page, though I suspect we'd do that as part of the metadata
editing consolidation.
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125

Ah, yes, I forgot about removing the portlet.
The case in this bug now looks a bit better, but still unreadable :(
Opening the bug again

I wonder if there's a different algorithm we can use? I suspect that even without the portlet taking up space that diagram will be pretty squeezy..

On Sun, Sep 7, 2008 at 4:23 PM, Christian Reis <email address hidden> wrote:

> I wonder if there's a different algorithm we can use? I suspect that
> even without the portlet taking up space that diagram will be pretty
> squeezy..
>

Not if you do it vertically.

>
> --
> Dependency chart becomes unreadable with >12 dependencies
> https://bugs.launchpad.net/bugs/66344
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Launchpad Blueprint Tracker: Triaged
>
> Bug description:
> The dependency chart is unreadable for any specification that has more than
> about a dozen dependencies. For example, <
> https://features.launchpad.net/products/launchpad-foundations/+spec/1.0-web-interface
> >.
>
> This could be fixed by making the dependency levels run vertically, rather
> than horizontally. This would work better because specification names are
> shorter than they are wide, so they could be packed more closely together.
>

--
The Data Charmer
http://datacharmer.org/

I was riding back home today in the rain and had an idea.

Instead of rendering the full dependency chart on every page where we display a blueprint which is part of that chart, we could only render the direct parents and children of that node on the page, and have a separate page which rendered the full tree in a readable scale. This doesn't help as much for nodes which do dependency explosions such as the one in the description, but those are problematic for other reasons (and I suspect they are mistakes in modeling your blueprints -- you knew I was going here didn't you?)

Working on removing the actions portlet

I removed the actions portlet in RF Fixed in RF 8163, allowing more space for the blueprints dependency chart. Hopefully it will address this bug. If not, please open up again :)