hi everybody! longtime user, first time poster.<br><br>i&#39;ve been kicking around a lot of ideas of things to do with ipython notebook: while the bulk of stuff is clientside, to get there, i think i need to do custom cells, which is a little more than ellisonbg&#39;s &quot;jsonhandlers&quot; branch does. further, as the specific capabilities exposed will require some pretty big depndencies (pdf generation, numpy, etc.) I am thinking about doing everything as python modules that are installed into the environment, rather than as purely drop-in javascript assets.<br>
<br>i&#39;ve started the work on github here:<br><a href="https://github.com/bollwyvl/ipython/tree/custom_cells">https://github.com/bollwyvl/ipython/tree/custom_cells</a><br><br>and a strawman cell provider here (does not contain working code, though it does load!):<br>
<a href="https://github.com/bollwyvl/ipython/tree/blockly">https://github.com/bollwyvl/ipython/tree/blockly</a><br><br>any insight is welcome!<br><br>to get my stuff in, i have used the setuptools iter_entry_points method I am familiar with... and defined a new entry_point, ipnotebook. plugins provide their list of assets and where one might find their static paths. can anyone comment on how this is (potentially) different from The IPython Way? The extensions stuff in the doc didn&#39;t look like they would be useful, so i gave up on trying to use that.<br>
<br>the structure of working with cells in master is pretty rigid right now, with the enumerated list of cells type in the code explicitly in the front end in several places, js and html. my initial work (in a addition to inadvertently recreating some of ellisonbg&#39;s work on the tornado app) has been to refactor all of those cases of adding buttons or whatever into something that looks at a window.IPython-scope plugin registry.... this is defined in cell.js right now, but maybe should be someplace else.<br>
<br>after i did discover ellisonbg&#39;s stuff, i saw the most recent work was on dependencies... during my stuff, i will look into frontend and backend asset managers: require.js and webassets come to mind. this would have the pleasant benefit of clearing up some of the mathjax complications, and would make plugin development a lot more robust, if not simpler... also, if a user installed the kitchen sink of plugins, which started adding a lot of javascript assets, ideally a user should not see significant notebook slowdown until they were actually using new features.<br>
<br>looking forward to working on this over the holidays, and would love to have some fun things to show come 2013!<br>