Bug in igraph.plot() in jupyter

[Benfeitas]

I'm running python igraph in jupyter, and found a weird bug:

When I include the 2nd cell (the one after package importing), running the 3rd cell renders weird labels.

However, deleting the 2nd cell renders everything normally. I have tried copying all these cells to a new notebook but to no avail.
Untitled2.ipynb.zip

I'm attaching a .ipynb with all cells, hopefully you can reproduce this issue.

[Benfeitas]

To note, the labels on the 2nd plot are changed automatically as soon as I evaluate the first one. I.e. commenting the line ig.plot(g2, ...) fixes the issue.

[vtraag]

I'll have to look into it further, but at first sight it seems related to issue #222.

[iosonofabio]

I agree that seems to be the thing.Good ol' HTML/JS not having namespaces makes everything global and prone to these kinds of corruptions.

One suggestion was we reparse the svg file coming out of Cairo and make the node ids unique. Doable if a bit dirty.

[vtraag]

It might also be an option to simply default to PNG for displaying in Jupyter notebooks, see also #36. I'm not sure how matplotlib handles this.

[ntamas]

Apparently IPython (and most likely Jupyter) can wrap SVGs inside an iframe to avoid these kinds of corruptions, see this PR. I haven't had time to deal with it, most likely we should read the PR and see how we can give hints to IPython that our graphs should be placed in iframes.

[ntamas]

Actually, here's the solution. Anyone willing to pick this up? :)

[vtraag]

It seems that is already merged in PR #148?

[vtraag]

Btw, it seems that matplotlib uses a salt for the IDs: https://github.com/matplotlib/matplotlib/blob/477c1dcbe1a6aaed57d2e4b7210b47a6e8d4d73d/lib/matplotlib/backends/backend_svg.py#L317. Perhaps that is also a good suggestion for the long term for cairo.

[ntamas]

Well, it's been a long time ;) It could be the case that the fix is already merged. In that case, we only need to wait until 0.8.0 is released; in the meanwhile, @Benfeitas can use PR #148 as a workaround.

[vtraag]

I guess we can also close #36, pointing to PR #148?

[ntamas]

I think #36 has a different goal, allowing the user to switch between PNG / SVG / PDF representations on-the-fly. It also seems to contain some hackery to change the size of the plot after it was constructed; we could probably do better than this if we changed igraph’s Plot class as necessary. I probably won’t have time to deal with #36 in the near future to figure out which parts of it are still relevant, but I would definitely leave it open in case someone has the time to pick it up.

…

On 2019. Aug 23., at 6:44, Vincent Traag ***@***.***> wrote: I guess we can also close #36, pointing to PR #148? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[vtraag]

Sorry, wrong number :) I meant #222 instead of #36.

[ntamas]

Yes, #222 can be closed.

…

On 2019. Aug 24., at 15:52, Vincent Traag ***@***.***> wrote: Sorry, wrong number :) I meant #222 instead of #36. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.