all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: d3js chord diagrams
Date: Tue, 25 Oct 2016 14:52:18 +0200	[thread overview]
Message-ID: <878ttc7fr1.fsf@gnu.org> (raw)
In-Reply-To: <87oa28hfjk.fsf@elephly.net> (Ricardo Wurmus's message of "Tue, 25 Oct 2016 12:46:39 +0200")

Ricardo Wurmus <rekado@elephly.net> skribis:

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

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	other threads:[~2016-10-25 12:52 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
2016-10-25 12:52     ` Ludovic Courtès [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878ttc7fr1.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.