Add jupyter integration for lets-plot-kotlin and lets-plot-kotlin-geotools
- Solves #244.
Add Jupyter Integration plot-api and toolkit/geotools modules. All the old logic (imports/init/renders) from descriptors has been moved into them. Updated descriptors are in this PR.
A new type returned by rendering has also been added, which allows you to use the following features that are now available for Kandy plots in Kotlin Notebook:
- Native rendering in Swing;
- Dynamic IDEA theme application for plots (only for plots where flavor is not specified);
- Export plot from cell in different formats (PNG, SVG, JPG, HTML);
- Copy plot (as PNG) from cell;
Added letsPlotNotebookConfig variable (in notebooks only) which allows to disable native rendering in KTNB.
These changes do not affect Jupyter and Datalore notebooks.
Also this rendering adds static SVG in the output, hidden by script which allows to show static part of plot on GitHub/Gist.
Several simple tests for Jupyter Integration are also added.
I've run into the problem that the latest versions of the Kotlin jupyter api use java 11, which makes it completely incompatible with geotools module, and partially with plot-api. In particular, I had to add different versions of the plugin to them because of this. But it's clear that this is a bad solution. @ileasile suggested the following: https://github.com/Kotlin/kotlin-jupyter-libraries/pull/421#issuecomment-2399998252
I suggest adding lets-plot-jupyter and lets-plot-geotools-jupyter modules. They should have all dependencies that are now listed in corresponding descriptors, and also integration classes. Also, they should target 11th version of JVM bytecode. I'm ready to pair-program it with you if there are any problems in implementation
Shouldn't be difficult, but I'm interested in @alshan opinion.
Jupyter integration doesn't belong to the "plot-api" project in my opinion. Let's move it to a separate project nested in the 'toolkit' folder? Can have java 11 as a target there.
@alshan, we can fix the version of the lets-plot library (and, but not necessarily - js) when compiling the artifact with integration. This will help user to avoid version incompatibility. That is, there will be only one version in the descriptor - Lets-Plot Kotlin, one dependency that will load the lpk of this version and lp corresponding to it (bundled at compilation). What do you think?
And of course it will avoid cases when the integration code is written on a version incompatible with the specified in argument.
Do you mean drop arguments in %use lets-plot ?
Yes. There will be only one dependency on lets-plot-kotlin-jupyter, that will load lets-plot-kotlin with the same version and lets-plot artifacts with tge corresonding for this lpk versions.
Sounds good.
Extracted integrations to separated modules jupyter and geotools-jupyter. These modules creates artifacts with all LP and LPK implementation (and all geotools implementations for geotools-jupyter) and can be used in notebooks with updated descriptors (this PR with descriptors should be merged with the versions of integration artifacts inserted).
Also added "util" module and artifact - it contains Lets-Plot spec serialization and deserialization methods. It's used internally in Integration and should be used externally in Kotlin Notebook plugin (now it uses "kandy-util" similar artifact, but it's better to store it here, since it's related to Lets-Plot, for future changes; also it can be very useful for users who want to have Lets-Plot spec serialization).