[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: d3js chord diagrams
From: |
Ludovic Courtès |
Subject: |
Re: d3js chord diagrams |
Date: |
Tue, 25 Oct 2016 14:52:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Ricardo Wurmus <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
>
>> Ricardo Wurmus <address@hidden> skribis:
>>
>>> I’ve built something:
>>>
>>> http://elephly.net/graph.html
>>
>> Awesome! Much better than staring at a static graph in Evince.
>>
>>> I’ve tried earlier to build a force-directed graph to visualise the
>>> package dependency graph, but I had to realise that a force-directed
>>> graph with the number of links and nodes that is common in software
>>> dependencies is visually indistinguishable from a cat’s hair ball. In
>>> contrast I find the chord diagram to be much clearer.
>>
>> Are there other types of visualizations supported by d3 that would help?
>
> Yes. A force-directed graph could be made clearer by applying force
> bundling as is done here: <https://github.com/upphiminn/d3.ForceBundle>.
>
> We could map the graph to a collapsible tree such as this
> <http://codepen.io/mikefab/full/IDdts/>. One disadvantage of using a
> tree is that we can no longer visually unify shared inputs.
>
> We could also provide a variant of the chord diagram by bundling edges
> as is done here:
> <http://mbostock.github.io/d3/talk/20111116/bundle.html>. We’d lose the
> relative “importance” of a package, which in a chord diagram can be seen
> in the radial size of a segment, but dependencies might be clearer.
Looks nice.
> So, lots of things that a dedicated hacker could implement :)
Is it a lot of work with d3 to switch to these other representations?
>> An option is to download it to the store on demand. The downside, of
>> course, is that it would require network access.
>>
>> If the .js files were to be installed, I agree with using PREFIX/lib/js
>> as Pjotr suggests.
>
> Does this mean that the generated HTML document would have to be a gexp
> referencing the file in the store? (I’m not sure how to implement
> this, but with a pointer or two I could give it a try anyway.)
Yes, the HTML document would be generated in the store, so at some
point, you’d have:
(define (generate-html js-file)
(computed-file "graph.html"
#~(begin
(use-modules (sxml simple))
(call-with-output-file #$output
(lambda (port)
(sxml->sxml `(html
… #$js-file
…)
port))))))
where ‘js-file’ is d3.js (likewise for graph.js.)
Ludo’.