From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: d3js chord diagrams
Date: Tue, 25 Oct 2016 12:46:39 +0200 [thread overview]
Message-ID: <87oa28hfjk.fsf@elephly.net> (raw)
In-Reply-To: <87h980ajkp.fsf@gnu.org>
Ludovic Courtès <ludo@gnu.org> writes:
> Ricardo Wurmus <rekado@elephly.net> 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.
(Graphviz-style representations are more difficult, because the location
of the nodes needs to be laid out first, whereas in d3 no
pre-computation takes place.)
So, lots of things that a dedicated hacker could implement :)
>> I turned this into a backend for “guix graph”, so that you can generate
>> There are a couple of implementation issues that I’d like to get input
>> on before submitting a proper patch. This depends on “d3.v3.js”, which
>> I’ve downloaded from http://d3js.org/d3.v3.js. (This is not minified
>> and thus rather large.) In my current implementation the contents of
>> this file are embedded in the report, because we don’t serve this file
>> at a well-known location. Is this okay? We probably could use file://
>> links, but that requires knowledge about where this file is located.
>
> What about having a fixed-output derivation (aka. ‘origin’) to download
> that file from a stable, versioned URL?
>
>> If it is okay to bundle d3js with Guix, where should it be installed?
>> How can graph.scm know about the location of this file after
>> installation? Should I add the path to d3.v3.js to
>> “guix/config.scm.in”?
>
> 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.)
>> Should this go to “$out/share/guix/”? How would these files be found
>> when using “./pre-inst-env”?
>
> Well, if it’s just the small graph.js, you could store it in moduledir,
> like we do for patches. This is a hack, but the advantage is that we
> can just use (search-path %load-path …) to find them, regardless of
> whether we’re using ./pre-inst-env or not.
Okay.
> Otherwise we could add a new GUIX_JAVASCRIPT_PATH env. var. and
> corresponding ‘search-javascript-file’ procedure.
I like this a little less than the “search-path” option.
~~ Ricardo
next prev parent reply other threads:[~2016-10-25 10:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 22:09 d3js chord diagrams Ricardo Wurmus
2016-10-22 10:37 ` Alex Sassmannshausen
2016-10-22 17:42 ` Pjotr Prins
2016-10-25 9:01 ` Ludovic Courtès
2016-10-25 10:46 ` Ricardo Wurmus [this message]
2016-10-25 12:52 ` Ludovic Courtès
2016-10-25 13:37 ` Ricardo Wurmus
2016-10-25 16:29 ` Ludovic Courtès
2016-12-11 11:37 ` Ludovic Courtès
2016-12-11 15:24 ` Ricardo Wurmus
2016-12-11 19:51 ` Ricardo Wurmus
2016-12-11 22:59 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87oa28hfjk.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).