New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slideshow Service via nbviewer #52
Comments
I would think it belongs in nbviewer, just under a different url, e.g.
|
I agree with Min - it doesn't make sense to have different domains for each On Sun, Mar 10, 2013 at 3:52 PM, Min RK notifications@github.com wrote:
Brian E. Granger |
OK, I agree with you...I will do some experiments with the current nbviewer2 and maybe I can come up with a preliminary PR ;-) Damián. |
I just want to point at that spreading across multiple domain would allow Add to that the fact that you might want to add "download as md/rst/tex..." I know that we have money from the grant, but it is not unlimited.
|
El 11/03/13 03:52, Matthias Bussonnier escribió:
You also are right! I have forgotten the details about dynos and addons. |
I would like to have time to look at blueprints that might help. I would also like to try a pure tornado version which would have the big advantage of beeing asynchronous and not wait on every external request that the json is fetched before processing next request. I know you don't have acces to statistics, but we are around 2500 page view/day, so in average we are at third to half what current nbviewer can hold, so it definitively can't sustain peeks. |
OK, coming back here... We have nbconvert2 working strong in the new nbviewer... and I also know that nbconvert2 is currrently in a big rewritten procedure (and I pretend to help with this in any task I can), but I would like go forward in the implementation of a kind of "slideviewer" using reveal-based slideshows... I will be at SciPy 2013 in Texas with two talks ( I get the student sponsorship, so I will be there all the week! ;-) I hope we can meet you there again!):
and I would like to have a site like "slideviewer" functional for those days... I can build an unofficial "slideviewer", but I would like to have it under the IPython "umbrella". What do you think about that? Any feedback will be appreciate! Cheers, |
Any thoughts here? I know you are busy, just a yes, no, maybe or "don't bother me" would be right... he he... joke aside, any feedback would be great! Cheers. |
Oh, sorry for the delay. Totally forgot. I would say that if you have it working and hosted somewhere we can just have a subdomain pointing on it. I would not mind if this was part of the main codebase, and was just a config option. If I had to implement it, I would wait for nbconvert to be merged into IPython itself. |
I would like to have a functional site in the following weeks... maybe a subdomain would be great... |
@damianavila Any status on this? I feel like most people use nbconvert to create their reveal.js powered slideshows (thanks to you+team), or add some CSS to their notebooks. What do you think now? |
I think we would need a general way of using many converter through nbconvert. |
Regarding the issue, I have working on this with the new tornado nbviewer infrastructure, but I have problem when I try to deploy it to heroku... I follow the step in the readme but without too much success. BTW, my solution is not general, it is slideshow specific, a clone of nbviewer suited for reveal.js... but it can be a beginning after we achieve something more general... |
We're about to flip this on its head, letting users make a PR that we then can deploy automatically (after being manually off by a member of the team). As for recipe, currently everything is deployed via these salt states. I haven't worked with the heroku setup in a while. What would be easiest for people to deploy with? Honestly, I could make a vagrantfile that pulls straight from those same salt states to deploy whatever fork (local or remote) of nbviewer you want. Would that be overkill or would it be useful? |
If I have a way to look a deployed version of my branch, it does not matter to me if it is heroku or something else... I just need a deployed version to begin with the debugging steps, to check if everything work as I expect... |
OK, I have a working and nice version of IPython Slides Viewer... you can see it in action here: http://www.youtube.com/watch?v=K3tLBgNxMus The question is what we do next... I submitted a WIP PR #150 you can test here (in fact, it is a fully functional version, ready to deploy after some changes in the index) The implementation is simple, I added reveal.js inside static folder and modified the app.py to call the SlideExporter instead of the HTMLExporter. Also, I have change the notebook.tpl to render the slideshow structure (as the reveal_slide.tpl inside nbconvert). So, I see two options from here:
I saw pros and cons with both possibilities, so I would like to know your opinions. |
@damianavila, great demo by the way! Just wanted to ask how you think the options of the default theme or color or font could be specified by the notebook author? It looked like they were currently changed afterwards within the URL. Would that involve more meta data option drop downs during authoring the notebook? Or could one imbed more detailed reveal.js inductions inside a hidden cell. Could this be customized to allow for changing background colors or transition types in mid-presentation like that in the demo slides for reveal.js? This really is a neat direction to extend research to shared coding, to publication, all the way to presentation. Thanks for your work. |
@ruffsl Thanks!
Yes, you can change themes and transitions (and other properties) querying the url, as with the "typical" reveal demo slideshow.
There are a lot of possibilities... probably using additional metadata we can change a lot of things... and probably we will develop a way to let the author changes these properties. The notebook currently support metadata at the cell level, but also at the notebook level, so we have places where to add useful information. Just we need to develop the proper infrastructure inside nbviewer (and by extension, inside slideviewer) to read this additional info...
I think in the same direction... presenting your data is probably the final step of your research... and if we can provide a tool to make this step better, we are on the right path.
Thanks for your comments! |
Took a stab at implementing The changes are really quite minimal. I think going to named groups would be a little more consistent, but this seems to work... i ran out of API hits before taking a screenshot, but it seemed pretty good for the example I found: https://github.com/damianavila/vIPer/blob/master/IPython-powered_Slideshow_Reveal-ed.ipynb Hopefully not too far away from being able to make this happen! |
Hey @bollwyvl, nice! thanks for took an stab on this!! Can you make it official, I mean... make a PR so we can start discussing on it... Thank you very much!! |
Hi @bollwyvl and @damianavila ... this is very timely, I hope that these updates fix latex rendering issues soon (before Tuesday 😄) so I can use the slideviewer to distribute slides for a talk I'm preparing. |
@damianavila: created #359! |
ok. Thanks! |
yep, this could take some days... so please use nbconvert to make your slides as a backup option... |
Fixed with #390. |
Ok, this issue is mainly to discuss how we will deal with a service such as nbviewer2, but for reveal-based slideshow...
Some time ago with @Carreau and @ellisonbg we discuss a little bit about that...
Now, that we have nbviewer2 going strong, I came up to discuss about this issue... before implementing some things ;-)
What do you think about that? I would be easy to add a button (and the functionality to render...) for slideshows in the current nbviewer2, but maybe we want to keep it isolate, just nbviewer2, and get another domain with a twin "slideviewer".
Cheers.
Damián.
The text was updated successfully, but these errors were encountered: