guix-devel
[Top][All Lists]
Advanced

[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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]