Hey, folks! An update: I've been tinkering with an even crazier branch which adds:

• diagrams embedded inside ipynb
  • the good
    • the workflow is really quite nice: make a plot (preferably in svg), drag it into drawio, save clears the dirty state on both dockpanel items.
  • the bad
    • some weirdness due to "special" things that happen around notebook paths/contents in lab
    • dragging rendered markdown in... works... but lots of things are weird (text gets theme-derived styling)
    • text wrap not so good
• PDF export
  • the good
    • a prototype ipywidgets toolchain for combining multiple drawio files (dio, png, svg, or ipynb) into one PDF
    • supports jinja templates
    • embeds (composite) drawio XML into generated PDFs
  • the bad
    • links don't work
    • no metadata tagging (e.g. outline)
    • nodejs, puppeteer, chromium on the server... perhaps if the nbconvert/pyppeteer stuff gets a little more robust, i can piggyback off that
    • while connecting the nodejs stuff with jupyter-server-proxy is pretty easy, it might be better as dedicated serverextension

Next steps:

• after having demoed this a few times: there's always that guy that says, so why doesn't the plot update?
  • the thought is to write a drawio plugin which exposes all of the rendered markdown and outputs inside drawio so they can be updated whenever their "parent" object changes... the above linked drawio issue points to some of the issues I'm encountering.
    • ideally, the plugin would be pretty lightweight (e.g. not introduce a new geometry, as that would drastically reduce the portability) but instead just use some metadata
    • JUPYTERLAB_DRAWIO_CELL_NAME would be the cell name
    • JUPYTERLAB_DRAWIO_CELL_PART would be either source or outputs
    • JUPYTERLAB_DRAWIO_CELL_OUTPUT would be a number
    • JUPYTERLAB_DRAWIO_CELL_OUTPUT_MIME would be the mime bundle key to pick off, and then encode
• using pdfjs to make the roundtrip even more seamless, e.g. Drawing.dio.pdf, for the price of a slower save, would always be up-to-date with what you last saved

this is awesome!

Hey, y'all: I know your team is super busy... I've been advocating for (and using) mamba quite a bit 😍 , and don't even have anything to complain about yet (you know I would if i did). But I've been getting a lot of use out of my various branches off this repo, and am considering publishing some pre-releases, probably under @deathbeds.

The goals motivating this:

• deeper notebook integration (e.g. syncing outputs) needs to be its own package
• some of the drawio plugins (which we can start using now that they fixed some path stuff) I want need to be their own packages (e.g. multi-mb autolayout packages with WebWorkers)
• using jupyterlab-videochat to backhaul drawio's collaborative editing over jitsi's XMPP pipe needs to be its own package
• testing/CI in anger
• re-doing the PDF export in python as an nbconvert or serverextension

As my forks are, in a not-even-that-mergeable-upstream state, it's kinda hard (and slow) to be sub-moduling them into the tools/demos where I want to try things and re-building them everywhere: real (pre)releases of this crazy stuff would make it a lot more robust.

I'm still very much interested in getting these features to users of this extension... and the name and licensor changes, keeping it BSD-3-Clause, would be revertible in the future, but there will probably be a fair amount of infrastructure changed (probably lerna, doit, robotframework, etc.) to start helping me stay sane while working. These might be too many opinions to introduce to this repo. But hackers gotta hack...

@bollwyvl thanks for all the nice words, and for advocating mamba! It's true that I am putting most of my time into that project right now, so that too little is left to get jupyterlab-drawio where it should be.
I am totally happy to make you the responsible person for the future of this extension! :) lets check what @SylvainCorlay has to say.
Would you want to keep it under QuantStack or should we figure out a way to move it to one of the Jupyter orgs?

I've got the first of those pre-releases up over at https://github.com/deathbeds/jupyterlab-drawio.

Onward!

Hey folks: I just dropped ipydrawio v1.0.0a0, which includes this work... guess I'm going to close this one!

Hey @bollwyvl thats awesome. Sorry for not having enough time to give this the attention it deserves :(

@bollwyvl you should come to our chat! we are working on adding collaborative editing to jupyterlab, and one of the potential showcase extensions will be jlab-drawio :) We're going to use Y.js and we're funded for this work. It's going to be quite amazing.

Welp... having been down the RTC road a couple times, it's a really awesome when it works!

My thinking on the jitsi/dio piece: multi-user collaborative drawing is a proven, useful activity, that would benefit teams i work with right now. Full-fat drawio has its own (as you can no doubt imagine, home-rolled) mechanism for doing file sync which very well might just work with the pipe offered up by jitsi, which would improve the utility of both of them as extensions. I'm basically trying to invent as little as possible these days, and integrate with the best stuff I can, leaving as many API hooks open as possible.

The ugly parts of my experiences: the general semi-structured case (like a notebook) is... hard. Handling trust and identity is... hard, especially if federated. Fine-grained permissions is... really hard. Handling shared compute is... not something i have tackled as server thing, much less a decentralized thing, and don't even know what that would mean. yjs is a solid play, for sure, if something needs to be built from the ground up.... and the team has already solved all those things. I was impressed at how well it worked with prosemirror.