Skip to content
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

Confused by navigation: space and shift-space skipping certain sublisdes / fragments #49

Open
nthiery opened this issue Aug 31, 2023 · 4 comments · May be fixed by #65
Open

Confused by navigation: space and shift-space skipping certain sublisdes / fragments #49

nthiery opened this issue Aug 31, 2023 · 4 comments · May be fixed by #65
Labels
bug Something isn't working

Comments

@nthiery
Copy link
Contributor

nthiery commented Aug 31, 2023

Description

JupyterLab-Deck sounds very promising.

However, coming from rise / reveal, I am used to space (resp. shift-space) to move through the whole
slide show by minimal step; e.g. move to the next (resp. previous) available fragment/subslide/slide.
However, in certain situations, space skips subslides. And in certain situations, shift-space skips
fragments and subslides. In particular, space and shift-space are not reverse operations.

Is this on purpose or a bug?

Thanks!

Reproduce

  1. Launch the jupyterlab-deck, e.g. from the jupyterlite demo.

  2. Upload the attached
    test.ipynb.zip (sorry, zipped, because github does not support ipynb attachments ...)

  3. Open test.ipynb notebook

  4. Toggle Deck
    The (first fragment of the) first slide is displayed

  5. Hit space
    The following fragment is displayed

  6. Hit space
    Expected: the following subslide "Subslide1" is displayed
    Got: the subslide "subslide2" is displayed

  7. Hit space until reaching Slide2

  8. Hit shift-space
    Expected: Subslide2 and its fragment is displayed
    Got: Slide 1 is displayed

Context

  • Browser: Firefox 117

No message in the browser console, except for standard GET calls to kernels/sessions/...

@bollwyvl
Copy link
Contributor

Yep, there was some cheating done. Correct, predictable navigation probably needs to be generalized as a parallel hierarchical finite state machine (e.g. xstate). Things also get complex when authoring a deck directly in deck view (adding new cells).

@nthiery
Copy link
Contributor Author

nthiery commented Sep 20, 2023

Just for the record: if I make all subslides into slides, then Space / Shift-Space navigation
is smooth. So a quick fix might be to have a dedicated Space/Shift-Space navigation
that just ignore the difference between slides and subslides.

@brichet
Copy link

brichet commented Jan 11, 2024

@nthiery @bollwyvl I can take a look at it.
Just wondering what should be the correct workflow.
Let's say we have the following schema:

Slide 1
   Sub slide 1.1
   Sub slide 1.2
Slide 2
   Sub slide 2.1

Pressing right arrow from Sub slide 1.1 should redirect to Slide 2.
But then, should pressing left arrow (or shift space) redirect back to Sub slide 1.1 or to Sub slide 1.2 ?

The first case would require keeping the state of each slide when moving to another slide.

@nthiery
Copy link
Contributor Author

nthiery commented Feb 2, 2024

Oops, I missed your question. I am not sure myself what the semantic should be
for left/right arrow (I rarely use them). reveal.js being widely used, following the
same convention is presumably a safe starting point:

https://revealjs.com/vertical-slides/

The documentation there is a bit ambiguous. However my understanding of the
default behavior is that, when moving back and forth from one stack to the other,
one always lands on the first slide of the stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants