search

jupyter-widgets / pythreejs

A Jupyter - Three.js bridge
https://pythreejs.readthedocs.io
Other
951 stars 188 forks source link

WIP: Initial roadmap thoughts #54

Closed abelnation closed 6 years ago

abelnation commented 8 years ago

@jasongrout @SylvainCorlay

Starting out with just ideas, which can then be sorted into something more prioritized and defined. Also, would using a wiki page be a better format for road-map? or is file-in-repo preferred?

SylvainCorlay commented 8 years ago

Thanks for getting the ball rolling on this.

I have a couple of other ideas:

  1. live gallery of example utilizing the technique that we used for http://jupyter.org/widgets.html This will help engaging more users and contributors.
  2. provide method for resizing the renderer in a meaningful fashion to be eventually wired with phosphorjs resize events. Since jupyter widgets are moving to phosphor, this will soon be important.
SylvainCorlay commented 8 years ago

Regarding the roadmap format, I think that a file in repo has better chances of being maintained. @jasongrout thoughts?

jasongrout commented 8 years ago

Also conversion to typescript, like Jupyter js widgets. Actually, that might be best to do first, as the static typing will help catch errors

jasongrout commented 8 years ago

+1 on a file in repo

abelnation commented 8 years ago

@jasongrout would converting to typescript require full typescript bindings for all dependencies? e.g. three.js bindings? I'm not super familiar with typescript's requirements or how it handles outside deps

abelnation commented 8 years ago

The more I go in to look and tweak specific files, the more I think there is a middle-of-the-road solution to auto-generate a ton of these boilerplate wrappers. Basically, the script could auto-generate a wrapper for any file not already present in the source code. With such a script, the complicated modules could be hand-written, while the simple ones could be auto-gen'ed. You can distinguish between autogen files and manual files with an extension, e.g. .js.autogen and then leverage webpack to be smart and just require in the right file, e.g. 

var Object3D = require('./core/Object3d');

Would look first for a .js file, then .autogen.js. Webpack supports such smart resolving of modules.

Will holler when i have something to look at.

abelnation commented 8 years ago

After thinking about TypeScript a little bit, I actually am not sure it's a good move for this repo. Seems to me that pythreejs is one of the 3 main repos you guys use as substantial examples that use the jupyter-widgets framework. In general, I think its good to keep examples like that in a more pure form so that they're accessible to a wider audience. Maybe ES6 (using babel) is a good fit, but TypeScript does not feel like it has the wide adoption it needs to be appropriate for a showcase repo like this (I would make the same argument for bqplot)

SylvainCorlay commented 8 years ago

After thinking about TypeScript a little bit, I actually am not sure it's a good move for this repo. Seems to me that pythreejs is one of the 3 main repos you guys use as substantial examples that use the jupyter-widgets framework. In general, I think its good to keep examples like that in a more pure form so that they're accessible to a wider audience. Maybe ES6 (using babel) is a good fit, but TypeScript does not feel like it has the wide adoption it needs to be appropriate for a showcase repo like this (I would make the same argument for bqplot)

Agreed. We are more likely to switch to typescript for bqplot though, but it is not an immediate objective for us.

vidartf commented 7 years ago

What are current thoughts on switching to typescript or alternatively ES6 (https://kangax.github.io/compat-table/es6/)? I'm also playing with the thought of keeping the code JS, but autogenerating typings (.d.ts files) for it.