[brainstorming]Slideshow extension #2193

Closed
wants to merge 19 commits into
from

Projects

None yet

8 participants

@Carreau
Owner
Carreau commented Jul 23, 2012

Brainstorming about slideshow extension.

Fernando used a draft of this to make one of his talks.
It hides the cells, and show them one after the other one, groups by group.

Right now it uses some custom mark into code cells and markdown cell.
So the question is how do we tag cell and what kind of tag do we need.
What should be the UI.

The answer of the first question is certainly : we add store thing in metada.
for the information/type of metadata I suggest :

  • first cell of a group
  • next stop inside a group.
  • cell where input should not be shown
  • cell where output should not be shown
  • cell where out should be shown in the step after input
  • cell that should be shown line by line.
  • cell not show at all.

All this not alway exclusive.

About the UI, tink that the line by line UI can use gutter breakpoint to setup stop.

But how do we make the rest of the UI ?

@ellisonbg ellisonbg commented on the diff Jul 27, 2012
IPython/frontend/html/notebook/static/js/maintoolbar.js
+var IPython = (function (IPython) {
+
+ var MainToolBar = function (selector) {
+ this.selector = selector;
+ if (this.selector !== undefined) {
+ IPython.ToolBar.apply(this, arguments);
+ // move the rest ouside
+ this.construct();
+ this.addDropDownList();
+ this.bind_events();
+ }
+ };
+
+ MainToolBar.prototype = new IPython.ToolBar();
+
+ MainToolBar.prototype.addDropDownList = function() {
ellisonbg
ellisonbg Jul 27, 2012 Owner

Let's not use camel case in the Javascript, so add_dropdown_list here.

@ellisonbg ellisonbg commented on the diff Jul 27, 2012
IPython/frontend/html/notebook/static/js/maintoolbar.js
+ .append($('<option/>').attr('value','heading8').text('Heading 8'))
+ );
+ }
+
+ MainToolBar.prototype.construct = function() {
+ this.addButtonsGroup([
+ {
+ 'id':'save_b',
+ 'label':'Save',
+ 'icon':'ui-icon-disk',
+ 'callback':function(){
+ IPython.notebook.save_notebook();
+ },
+ },
+ ]);
+ this.addButtonsGroup([
ellisonbg
ellisonbg Jul 27, 2012 Owner

Again, no camel case.

Owner

In terms of the UI, could you summarize what the current special marks are?

I don't know how sophisticated we want to get. What about using something really simple, like using a markdown cell with an <hr> to indicate slides. The thing that is nice about that is that it looks good in the regular notebook. But I agree that if we want to use a more sophisticated approach, using metadata is a good idea. Also, I think we want to keep things really simple so it is trivial to use.

Owner
Carreau commented Jul 27, 2012

Right now, the used separator is #==== for code cell
<!--#====-->for markdown to be invisible.
If I remember correctly, we agreed on not using special cell for separation.

Just see this PR as an area of discusion of

  • first, what do me want the slideshow to be able to do
  • second, what should be the UI/marks
  • then i'll do something and force push as the code right now is just a big hack.
Owner

My memory is fuzzy; I don't remember agreeing to not use a special cell type for this. I don't like the idea of having to put comments the the cells - it gets in the way of using the notebook as a regular notebook and it looks ugly. We need to get other's comments, but as of right now I see two options:

  1. Just use a markdown cell with <hr> as the slide separator. This is simple and also looks good as a regular notebook. It is also easy to work with a move cells around between slides.
  2. Go all of the way and attach metadata to cells to specify how they function in the slideshow. This would be much more complex and require some UI work to implement the editing of that metadata. It would also be more difficult to see where slide boundaries are in regular mode and would be difficult to move cells around.

I guess I favor the simplified approach. Instead of using just a markdown cell with <hr> we could have users use a div with some custom class. We could use that class to style the slide boundary and could also use HTML data attributes to allow the user to pass in options for that slide. Or I suppose we could wrap that logic into Javascript and create a Python Slide object that a user creates in a cell. Hmmm...

Owner
Carreau commented Jul 28, 2012

My memory is fuzzy; I don't remember agreeing to not use a special cell type for this.

Sorry, the "we" where we at SciPy

Just use a markdown cell with <hr> as the slide separator. This is simple and also looks good as a regular notebook. It is also easy to work with a move cells around between slides.

but it takes a non negligeable amount of space.

If I remember correctly, at scipy we agreed on the fact that both special cells and comment will make people copy their notebook only to get one for presentation.

What I would do is something closer that what github does when you want to edit comment. when over in the upper right corner of a cell is show 2 buttons.

So imagine the following :

  • in the menubar an 'edit slides mode' button
  • when clicked those button apear.
  • you can toggle/cycle them.
    • first cell of a group
    • next stop inside a group.
    • cell where [ input should not be shown | output should not be shown | out should be shown in the step after input | inpu t should be shown line by line|cell not show at all]
  • it changes the metadata.
Owner

Sent from my iPad

On Jul 28, 2012, at 3:29 AM, Bussonnier Matthiasreply@reply.github.com wrote:

My memory is fuzzy; I don't remember agreeing to not use a special cell type for this.

Sorry, the "we" where we at SciPy

Ah, OK

Just use a markdown cell with <hr> as the slide separator. This is simple and also looks good as a regular notebook. It is also easy to work with a move cells around between slides.

but it takes a non negligeable amount of space.

If I remember correctly, at scipy we agreed on the fact that both special cells and comment will make people copy their notebook only to get one for presentation.

Yes, this is a good point and I think you are right that using metadata is a better option.

What I would do is something closer that what github does when you want to edit comment. when over in the upper right corner of a cell is show 2 buttons.

So imagine the following :

  • in the menubar an 'edit slides mode' button
  • when clicked those button apear.
  • you can toggle/cycle them.
    • first cell of a group
    • next stop inside a group.
    • cell where [ input should not be shown | output should not be shown | out should be shown in the step after input | inpu t should be shown line by line|cell not show at all]

I think we should keep it as simple as possible. As a first iteration, I think we should do something that only allows a user to indicate the first cell of each slide. That is really the I minimal data needed to present a notebook as a presentation, and it shouldnt take a user more than a few seconds to set that up.

  • it changes the metadata.

Sounds good. Why don't you see what you can do for a ui for this as you describe.


Reply to this email directly or view it on GitHub:
#2193 (comment)

Owner
Carreau commented Jul 31, 2012

@ellisonbg

can you tell me what you think about an UI like this ? https://github.com/Carreau/ipython/compare/_pmode
( it's a draft branch, so there is no need to review the code)

there are button on the top right of the cells, that can cycle through states, reflect this state in metadata, and fade away when in default state, stay visible otherwise.

Of course this should be visible only when edit presentation mode is activated.

Owner

I will have a look at this tomorrow.

On Tue, Jul 31, 2012 at 2:19 AM, Bussonnier Matthias
reply@reply.github.com
wrote:

@ellisonbg

can you tell me what you think about an UI like this ? https://github.com/Carreau/ipython/compare/_pmode
( it's a draft branch, so there is no need to review the code)

there are button on the top right of the cells, that can cycle through states, reflect this state in metadata, and fade away when in default state, stay visible otherwise.

Of course this should be visible only when edit presentation mode is activated.


Reply to this email directly or view it on GitHub:
#2193 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner

I am trying out the simply UI you created. Not sure if I am seeing the right thing. I see 3 buttons that stay in the same place on the page (upper R corner). They are labeled "button 1", "button 2" and "button 3". Not obvious what they do. Are you thinking that these buttons would set the relevant metadata on the currently active cell? The only problem I have with that approach is that it takes lots of clicks to do things: you have to go back and forth to activate cells and click the buttons. What about buttons that appear in the R part of each cell's input area when slide show edit mode is enabled? That way it is trivial to config the metadata for that cell.

Owner
Carreau commented Aug 12, 2012

hum, weird.
You should see 3 buttons on the upper-right corner of each cell.
I had this bug, I may have forgot some commits.
i'll check that.

This pull request passes (merged faedbd7 into 31afb62).

Owner
Carreau commented Aug 12, 2012

Please Try again now.
should look like this :
Imgur

Buttons shows only when hovered, or not in default state.

Code is not worth looking at, this is a junk branch.

Owner

OK this is better and I see roughly what you are saying I should. Comments:

  • There is a bug with the hover in/out. Often after I unhover, the buttons
    stay showing. It seems somehow related to if I have clicked on a button.
    When the notebook first loaded, all the buttons on all the cells were
    showing.
  • I am not sure we want the buttons to always be active. What about a
    "slideshow edit" mode that shows the buttons for each cell always. That
    would make it easier to see how each cell is configured without hovering
    over it. This would also allow us to use this area of the cells for other
    UIs in different modes.
  • The different button states seem a bit complex, and it is not at all
    obvious what each state does. Whatever we do, we need to develop a UI that
    requires no explanation. Can you summarize what each state does so we can
    think of how to simplify the model. Simplicity is key in the notebook.
  • Overall, I think this is a good place to put this UI and I like the
    button idea.
  • In my browser (Chrome OS X) the bottoms of the buttons are cutoff by
    something so you can't see their lower border. Maybe make the buttons
    slightly smaller?

On Sun, Aug 12, 2012 at 6:05 AM, Bussonnier Matthias <
notifications@github.com> wrote:

Please Try again now.
should look like this :
[image: Imgur]https://a248.e.akamai.net/camo.github.com/772789c913065ca879d7ca42bb9a919e32c373b7/687474703a2f2f692e696d6775722e636f6d2f47443065342e706e67

Buttons shows only when hovered, or not in default state.

Code is not worth looking at, this is a junk branch.


Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/pull/2193#issuecomment-7675486.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner
Carreau commented Aug 12, 2012
  • There is a bug with the hover in/out. Often after I unhover, the buttons
    stay showing. It seems somehow related to if I have clicked on a button.
    When the notebook first loaded, all the buttons on all the cells were
    showing.

Yes, this is something I tried, see if I can get the button to stick in some state and not in others.

  • I am not sure we want the buttons to always be active. What about a
    "slideshow edit" mode that shows the buttons for each cell always. That
    would make it easier to see how each cell is configured without hovering
    over it. This would also allow us to use this area of the cells for other
    UIs in different modes.

A slideshow edit mode was planed of course :-)

  • The different button states seem a bit complex, and it is not at all
    obvious what each state does. Whatever we do, we need to develop a UI that
    requires no explanation. Can you summarize what each state does so we can
    think of how to simplify the model. Simplicity is key in the notebook.

That was just to try. Id does not "do" anything right now. If I remember correctly

  • Group Stop == 'new header slide'
  • Slide Stop == 'show next cell af current slide'
  • In, Out : when showing a cell show In, then Out,
  • In & Out : when showing a cell show In and Out at the same time
  • In : when showing a cell show only In

... you see the idea

  • Overall, I think this is a good place to put this UI and I like the
    button idea.

Great, then i'll start to write something that does this but in a clean way.

  • In my browser (Chrome OS X) the bottoms of the buttons are cutoff by
    something so you can't see their lower border. Maybe make the buttons
    slightly smaller?

I do have this on chrome dev, but only for toolbar for a while... no idea why.
we'll tweek the css later.

bnmnetp commented Sep 28, 2012

This is brilliant.
I've been using ipython notebooks in two of my courses this fall to prepare lecture materials. (Computer Graphics and Computer Networking) Its so great to be able to demonstrate a lot of the vector applications in computer graphics without getting bogged down in my arithmetic errors on the whiteboard.

I've been looking for some way to make the material a bit more presentable than simply scrolling up and down in the browser. Then, I found this pull request and have been experimenting and running my notebooks with it and its great. I hope this is accepted and added to the main ipython distribution soon.

Brad

Owner
Carreau commented Sep 29, 2012

@bnmnetp Happy you got it running :-) we'll be happy to have feedback on it.
It is planned to add it, but it needs refactor under the hood :-)

If you use smth like this often, feel free to comment on what you wish you had, or what is wrong/annoying.
At least it will give us a clear view of what we have to achieve.

Thanks.

Owner

Now that the toolbar JS PR is merged this one can hopefully move forward. I am giving a talk using the notebook at PyData NY on Oct 26-28. Would love to use this to give the talk :)

Owner
Carreau commented Oct 2, 2012

I won't have much time to work on it a lot before end of next week, but i'll do my best to give you at least a working experimental branch.

From SciPy example, I know more or less what have to be done for it to be usable, and slide to be changed with keyboard or remote control.

Owner

About the design. could imagine that in the long run we will want many
different metadata attributes:for controlling slide shows. I think we
should develop this in an iterative manner:

  • Let's start with the simplest possible metadata attribute: "newslide".
    With that one alone, you can give slide shows.
  • Let's develop the UI that goes with that and make sure we like the design.
  • Let's merge that simple version to get it in people's hands.
  • Then let's add more features based on the feedback we get.

Another thing we should think about = some way of namespacing the slideshow
mode metadata attributes. I can imagine two ways:

  • Use a subdict name "slideshow"
  • Using name prefixes like "slideshow-newslide"

It would be good to standardize on this now. @minrk @fperez @takluyver,
any thoughts on this?

On Tue, Oct 2, 2012 at 12:41 PM, Bussonnier Matthias <
notifications@github.com> wrote:

I won't have much time to work on it a lot before end of next week, but
i'll do my best to give you at least a working experimental branch.

From SciPy example, I know more or less what have to be done for it to be
usable, and slide to be changed with keyboard or remote control.


Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/pull/2193#issuecomment-9084044.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner
Carreau commented Oct 2, 2012

Please have a look at this UI prototype. #2333

Another thing we should think about = some way of namespacing the slideshow
mode metadata attributes. I can imagine two ways:

  • Use a subdict name "slideshow"
  • Using name prefixes like "slideshow-newslide"

I vote for #1.

The main problem I have now with the UI to edit metadata is how do I add a button to every cell if the UI is already instanciated. I'm still thinking of this one, and haven't found a good way to do it, with a clean api to add buttons.

Owner

OK I am fine with the subdict approach for namespacing.

Are you thinking that the slideshow mode will be an extension, or something builtin? If it is builtin, then let's just create a methods on Cell called show_slideshow_ui and hide slideshow_ui. Would something like that work? Or are you thinking that you want a more generic way of adding UI buttons to cells. If that is the case, then let's create a div in the upper R corner of a cell when it is created and make a simple ui for adding buttons to that area. We could then have show_buttons and hide_buttons to hide or show all of them.

Owner
Carreau commented Oct 2, 2012

I would like a more generic way of editting metadata/adding button to cell. Nothing fancy but the ability to register a button that :

  1. toggle state (good candidate for new slide)
  2. cycle state ? drop down list ? (to see)
  3. call custom function that does what it have to do.
  4. others, but i don't remember.

In #2333 the only button is a type 3 button that pops the raw metadata as a dict, and edit it yourself.

It works great. and the toggling is css only by adding a simple class to <body>. So no need to cycle through cells.
my only problem is designing an api to register such a button function to all cell at once. Both already created cells, and cels that would be created later, without having to reload the notebook.

It is just the limit of my JS knowledge. And i'm reluctant to do something that will both loop through all notebook cells, and modify Cell class.

Owner

I think I would prefer to keep the UI simple and focused on presenting only the slideshow information for now. We can consider the general UI when the next set of usage cases comes up and we see exactly what it looks like. I worry that if we overdesign this now, we will have to redesign it later when we see exactly how it is used.

But if you want to tackle the general issue of cell level UIs and you see a nice way of handling it I would go for it.

I don't think we want to have the user edit the raw JSON dict in the UI. We want something that is more button and menu driven. Also, something that is keyboard shortcut friendly. Ha - wait I have an idea. The simplest way of getting this out the door would be to have no UI at all - just use a simple keyboard shortcut for toggling the newslide attribute. We could use our notification area to provide feedback like "New Slide On" and "New Slide Off". The only problem is that we couldn't look at the notebook as a whole and easily tell which cells are the start of new slides. But it might be worth thinking more about this approach.

I am fine with iterating through cells like you describe. Don't really see another way of doing it. You could put helper methods on the Notebook object that do the iteration for you - we already have methods like that - such as run all.

aterrel commented Oct 3, 2012

I've played around with the branch a bit. The hand editing the ipython notebook is clunky, but it is a great working draft. I could imagine a menu button that looks for the frame separators and pops up if they exist (or just a dropdown under View).

As far as visual component for the slides, I've been putting a horiztonal rule between each slide. That way for printing it makes since as one slide to the next rather than a long uninterrupted document.

Owner
fperez commented Oct 3, 2012

On Tue, Oct 2, 2012 at 12:58 PM, Bussonnier Matthias <
notifications@github.com> wrote:

Another thing we should think about = some way of namespacing the slideshow
mode metadata attributes. I can imagine two ways:

  • Use a subdict name "slideshow"

  • Using name prefixes like "slideshow-newslide"

    I vote for #1 #1.

Hmm... Let's think about it for a sec: do we really envision needing full
nested dicts? Why not make a simple convention that we use dots to
simulate nesting, just like in python, without the need to actually create
a new data structure?

I'm thinking of the metadata as having the following structure: keys can be
dotted, case in which they automatically create a nested namespace (much
like our config objects do). Furthermore, keys can have a value or not:
keys without a value are functionally equivalent to having an implicit
'True' value. This corresponds to using a defaultdict data structure with
lambda : True as the factory.

This would let us simply set slideshow.newslide as a key for new slides,
yet support more complex scenarios with minimal overhead.

Owner

I was thinking along these lines at first, but then starting to think about
the following:

  • It becomes difficult to query sets of attributes. For example, you could
    test to see if any "slideshow" attributes are set with a simple call to the
    JS equivalent of haskey('slideshow'). In the flat dotted approach, we have
    to write our own code for that logic - basically rewriting haskey for our
    flat dotted namespace.
  • It becomes easy to add/remove a full subdict easily in a way that doesn't
    require knowing anything about the inner keys.
  • We don't really have control over what people put into the metadata dict
  • eventually someone will put subdicts there.
  • Consumers/users of metadata can simply pull off the subdict they need and
    work with that. Otherwise they have to a) use the entire metadata dict or
    b) read individual attributes.
  • I imagine we will run into cases where there are default values of
    metadata attributes and then we will need to be able to merge default
    values with overrides. If we go with subdicts, it is easy to call $.extend
    on the subdicts. Doing so on the entire metadata dict would require us to
    first merge together all possible defaults into a single dict.

On Wed, Oct 3, 2012 at 11:21 AM, Fernando Perez notifications@github.comwrote:

On Tue, Oct 2, 2012 at 12:58 PM, Bussonnier Matthias <
notifications@github.com> wrote:

Another thing we should think about = some way of namespacing the
slideshow
mode metadata attributes. I can imagine two ways:

  • Use a subdict name "slideshow"
  • Using name prefixes like "slideshow-newslide"

I vote for #1 #1.

Hmm... Let's think about it for a sec: do we really envision needing full
nested dicts? Why not make a simple convention that we use dots to
simulate nesting, just like in python, without the need to actually create
a new data structure?

I'm thinking of the metadata as having the following structure: keys can be
dotted, case in which they automatically create a nested namespace (much
like our config objects do). Furthermore, keys can have a value or not:
keys without a value are functionally equivalent to having an implicit
'True' value. This corresponds to using a defaultdict data structure with
lambda : True as the factory.

This would let us simply set slideshow.newslide as a key for new slides,
yet support more complex scenarios with minimal overhead.


Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/pull/2193#issuecomment-9116600.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner
Carreau commented Oct 3, 2012

the distinction key/ attribute make no sens in js :

> a = {}
Object
> a['whatever']='data'
"data"
> a.whatever
"data"
Owner

Right, but Fernando is not proposing making the subdict have attribute
style access - he is proposing having the keys of the top level metadata
dict be strings with forms like a.b.

On Wed, Oct 3, 2012 at 2:08 PM, Bussonnier Matthias <
notifications@github.com> wrote:

the distinction key/ attribute make no sens in js :

a = {}
Object
a['whatever']='data'
"data"
a.whatever
"data"


Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/pull/2193#issuecomment-9122251.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner
minrk commented Oct 3, 2012

@Carreau - that's only true for keys that are valid identifiers, e.g. those without dots, spaces, etc.

Fernando's proposal seems to match matplotlib rc, if that has any relevance.

Owner
Carreau commented Oct 4, 2012

that's only true for keys that are valid identifiers

Yes I know that.

Fernando's proposal seems to match matplotlib rc, if that has any relevance.

I misunderstood.

But I agree with brian that nested dict are much easier IMHO.
For some configuration you could just grab a subkey (eg metadata.slideshow) and pass it as is to the slideshow object without having to merge all 'slideshow.smth' keys. This allow extension that would rely on metadata to use the structure they wish in their prefixed subkey.

More over in one day one extension is so much used that it becomes a i*nb standard. It will be easier to maby move it "outside" of metadata.

Owner
Carreau commented Oct 4, 2012

I think I would prefer to keep the UI simple and focused on presenting only the slideshow information for now. We can consider the general UI when the next set of usage cases comes up and we see exactly what it looks like. I worry that if we overdesign this now, we will have to redesign it later when we see exactly how it is used.

Ok, let's go for Presentation only for now.

But if you want to tackle the general issue of cell level UIs and you see a nice way of handling it I would go for it.

I don't think we want to have the user edit the raw JSON dict in the UI. We want something that is more button and menu driven.

No of course, raw is not ment for that, but is really powerful to develop. It would be great to have it enabled but css hidden.

Also, something that is keyboard shortcut friendly.

We are short on shortcut...

Ha - wait I have an idea. The simplest way of getting this out the door would be to have no UI at all - just use a simple keyboard shortcut for toggling the newslide attribute. We could use our notification area to provide feedback like "New Slide On" and "New Slide Off".

For some cases, I strongly disagree. for 2 reasons.

  • You send a notebook to SO. (this SO is you in 6month for example how do you know which slides are the new one ? Or if you have set one by mistake ? You need a permanent visual feedback( but you raised the point later) .
  • do a select/shortcut cycle is long and repetitive some actions woud be much better on cell level toollbar (I think of copy/execute/edit/cut) and are much more 'touch friendly'

Of course such a per cell toolbar would be hidden by default.

The only problem is that we couldn't look at the notebook as a whole and easily tell which cells are the start of new slides. But it might be worth thinking more about this approach.

I am fine with iterating through cells like you describe. Don't really see another way of doing it. You could put helper methods on the Notebook object that do the iteration for you - we already have methods like that - such as run all

I'll see what I can do, but i'm low on bandwidth.

Owner

I agree with your comments on the keyboard shortcut. A nice simple UI is probably better. I was mostly thinking out loud.

Contributor
tkf commented Oct 5, 2012

This is great feature an I can't wait to see this in.

A few points I couldn't find above (but maybe I miss them):

  1. Why not do it even without metadata? For example, let's assume h1 title as beginning of slide. Probably this is too trivial even for the first iteration.

    But I think making h1 as beginning of slide by default make sense. There are two ways to do this:

    1. Treat absence of metadata differently for different cell type. Notebook file will be simple, but JS code will be ugly.
    2. Add metadata for h1 cell at creation time. Notebook file will have redundant data but JS code will be simple. Also, slide show acts differently for old notebooks because it has no metadata.
  2. How about option for animating cell output? For example, if the output has text indicator using control sequence, it will be cool to see them moving. But I don't expect it to be in the first versions. I just though UI and metadata must be designed to allow this feature, if it is in plan.

Owner
Carreau commented Oct 5, 2012

Why not do it even without metadata? For example, let's assume h1 title as beginning of slide. Probably this is too trivial even for the first iteration.

Because :

  • you might not want h1 to be the beginning of the slide
  • you might want something else than h1 to be the beginning of the slide
  • This will lead people to make copy on notebook only to modify them in order to make slideshow. Which is bad.

There is the same discussion above for <hr> as separator.

How about option for animating cell output? For example, if the output has text indicator using control sequence, it will be cool to see them moving. But I don't expect it to be in the first versions. I just though UI and metadata must be designed to allow this feature, if it is in plan.

Lot's of things to do before.

  • Show only input,
  • Show only output
  • show code cell step by step
  • have keyboard navigation and ability to have table of content with clikable link

My wish would be to be able to stuff like that wiht cells/ group of cells :

Contributor
tkf commented Oct 5, 2012

My first point is to make h1 cell as a separator by default, not disallow everything else.

My second point is not adding animation for the first versions, but to help designing extensible UI/metadata.

Contributor
tkf commented Oct 5, 2012

Another point I just come up with: for hide/show options, don't you want to share them with another notebook export? For example, you don't want hidden code cell in slide show appeared in PDF output. Maybe yes in some case, but mostly no, I guess.

Owner

It would be quite easy to export a notebook to use reveal.js. A fun
afternoon of work on nbconvert.

Cheers,

Brian

On Fri, Oct 5, 2012 at 2:51 AM, Takafumi Arakaki
notifications@github.comwrote:

Another point I just come up with: for hide/show options, don't you want
to share them with another notebook export? For example, you don't want
hidden code cell in slide show appeared in PDF output. Maybe yes in some
case, but mostly no, I guess.


Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/pull/2193#issuecomment-9170558.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner
Carreau commented Oct 5, 2012

It would be quite easy to export a notebook to use reveal.js. A fun afternoon of work on nbconvert.

If a slideshow mode is note live editable, it is not a real slideshow mode.... :-)

Owner

Yes, the simple reveal.js export would not lead to an editable and runnable
slide show, but for exporting to pdf it would be nice.

On Fri, Oct 5, 2012 at 9:32 AM, Bussonnier Matthias <
notifications@github.com> wrote:

It would be quite easy to export a notebook to use reveal.js. A fun
afternoon of work on nbconvert.

If a slideshow mode is note live editable, it is not a real slideshow
mode.... :-)


Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/pull/2193#issuecomment-9181468.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

Owner
fperez commented Oct 23, 2012

Just noticed a conflict, hopefully easy to rebase...

Owner
Carreau commented Oct 23, 2012

WIll try to fix this quickly.

Owner
Carreau commented Oct 23, 2012

Forget this one, most of it is implemented in #2333. the 2 are too much entangled.

I'm closing,

@Carreau Carreau closed this Oct 23, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment