Hello! Current (probably all) versions of JupyterLab's imageviewer-extension treat all the supported image formats as base64. To my understanding, this means that a text contents model held by another Document of one of the two text-based types (svg and xbm) won't be updated as it is being edited.
I'd like to be able to live edit svg (but xbm might be nice, too?) with Editor (or another Document widget). No doubt there are other text-based image formats.
Over on QuantStack/jupyterlab-drawio#61 the drawio document can generate svg and png that retain their editability. The pngs reload like a dream, while the svg need to be reloaded (for which there isn't a button).
add an extra tracker to the existing extension, which actually yields two plugins
listen for same-file, different model and re-request (ick)
add an entirely new core extension, textimageviewer
change the imageviewer contract to be an (extensible) manager pattern than other images can extend
I'm happy to submit a PR, but seems like kind of a sticky wicket as to the best approach.
jsonviewer has similar behavior
The text was updated successfully, but these errors were encountered:
So seems CI is backed up, but #8495 looks alright..
I realized while trying it out that getting editable SVG to fit into the image box might indeed introduce additional shortcomings... perhaps what is needed (in addition to #8495) is a dedicated svgviewer and svgviewer-extension which can support opening an SVG in a dedicated iframe. This would allow for some of its cooler features, like clickable links, reactive CSS, and animations, to function properly, without stomping all over the DOM.
Given that SVG is pretty important to branding labextensions (core or otherwise), another feature this could provide would be a LabIcon preview... it took me a while to figure out what was happening with all the magic classes. Again, the iframe might be interesting, as you could preview the small multiple view of your icon at the various sizes (e.g. launch card, tab icon) by all of your currently-installed themes.
And finally, just because, even though everybody likes to poo-poo XML, it may be worth having a core XML viewer based on, e.g. https://github.com/storybookjs/react-inspector. That may also be a better JSON experience than the existing one. Though in my dreams i sometimes see a @lumino/datagrid with collapsible hierarchy, schema validation and other things for JSON/XML...