Flyspray - The bug killer!

Hey, great job done. I’ve played around with the graph and made it work for me.
What I’ve done is to create two new task “Step 1” and “Step 2” and I made step 2 dependend on step 1. That means that I have first to close step 1 before I can close step 2. In the graph it’s shown like “Step 2” → “Step 1” which means to me that in a serial order step 1 follows step 2. (Sorry for that lousy image but I’m not allowed to attach files.)
Is this a special way to show dependencies or is it my personal problem that I can’t understand the authors intention.
In other words, do I have to change it by my own or will it be changed in the future?

Andreas: I’m glad you like it. The graph is set up to draw so that if Task A depends on Task B, Task B will be below Task A. In your example, step 1 would be below step2. It isn’t meant to indicate the order of performing the tasks, like with a flow chart, but to show which ones depend on which. I set it up so that “depends” is illustrated like “builds upon”, so as the tasks below are completed, the tasks above can be completed. If you think of them like bricks in a wall, it makes a little more sense sense, but “below” means following an arrow more than just looking directly below it, at least when you get more than 3 or 4 dependencies, or more levels of dependency.

So the short answer, is I’m not planning on changing it, but if you wanted to change it in your local version, go down to about line 200 in scripts/depends.php, and change it from this:

$dotgraph .= “FS$src → FS$dst;\\n”;

to this:

$dotgraph .= “FS$dst → FS$src;\\n”;

When I click on “View Dependency Graph” I get...
>>

Warning: system(): Unable to fork [/usr/local/bin/dot -T png
-oattachments/depends_6.png C:\\WINDOWS\\TEMP\\fs_11B.tmp] in
D:\\inetpub\\vhosts\\boiledsweets.com\\subdomains\\dev\\httpdocs\\flyspray\\s
>> cripts\\
>> depends.php on line 213

Any chance this can be addressed?

(This came up on the mailing list and was discussed there last week.)

This task will address that problem by removing the requirement of a locally installed dot, so long as you allow it to send a bit of info to the remote dot image generation server.

Another thing I’m planning to do as I work on this is make the “tooltip”/title in the imagemap links more useful by presenting non-redundant data. Accessibility of the image is not much of an issue, because if you can’t see the picture, there’s not much point in clicking on the link anyway. So I’m planning to put things like severity, priority, status, and assigned-to (if applicable) in the tooltip.

If not many people are planning on printing the images in grayscale, I could also do more with the color coding, by showing severity with colors instead. Thoughts?

<BUMP> Oh go on please start work on this. I cannot install DOT or use system(). PLEASE...

Status update: the tooltip/title over the imagemap links have been updated as I proposed on Oct. 25, and the change was committed to svn in r465 on Nov. 8 to the devel version, and backported in r475 on Nov. 11 to the 0.9.8 branch.

I’m still looking for feedback on color coding, but if I don’t get any, it probably won’t happen.

The number of requests for this is rising, so I’m increasing it’s priority in my queue.

Pushed back to 1.0.