Dslide 1.0 Feature Roadmap & RFC

Dslide 1.0 Feature Roadmap & RFC

[Psionic K]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

Earlier, a single PR for supporting babel parameters was invaluable insight
into current features.  I don't use org mode in every way that everyone
uses org mode.  Different perspectives help.

I have compiled a list of everything I believe belongs in version 1.0:
https://github.com/positron-solutions/dslide/issues/20

Adding macro playback support:
https://github.com/positron-solutions/dslide/issues/18
This is of particular interest.  Along with babel, it's another
does-everything-Emacs-can-do feature.  It is a feature so dslide that
dslide cannot be dslide without it.  How do we want it to work?  What
should it build on top of?

The markup we will arrive at deserves intense focus.  It is a place where
good decisions now pay off later.  Every problem with actions now is a
result of markup and babel parameter choices I hadn't considered because I
don't use org that way.

I have gotten some nice views of Busan coming into port from the ocean
while recovering from food poisoning dealt by that same ferry, and I will
take this opportunity to stress the benefit of adding *fresh* hamburgers to
the hamburger jar.

I intend first to bring Master of Ceremonies (mc) onto MELPA.  I can see at
this point which features belong in mc and which ones belong in dslide.
The `mc-focus' command has been extremely beneficial for creating graphics
out of code and will become the focal point of mc's design.

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]

Re: Dslide 1.0 Feature Roadmap & RFC

[Ihor Radchenko]

Psionic K <psionik@positron.solutions> writes:

> I have compiled a list of everything I believe belongs in version 1.0:
> https://github.com/positron-solutions/dslide/issues/20

Thanks for sharing!
I tried the demo and I have several comments/questions:

1. May animations be disabled in the slides? They are not necessary most
   of the time in the real-world presentations

2. Slide navigation is sometimes a bit confusing. In particular the part
   about arrow navigation inside contents view and during the
   presentation
   - left/right inside presentation are ok and expected (I'd also add
     SPC DEL)
   - however, <down> is way too easy to use accidentally. Why not just
     C-x k? It is not like people need to quit frequently enough to have
     a very simple and easy-to-reach binding just for quitting
   - pressing up arrow twice from presentation does not go back to the
     slide being displayed. Instead, it goes to the first slide in
     top-level heading. Rather unexpected. In most presentation software
     one can toggle TOC/current slide (often, with TAB)

 3. For some reason, "Every Child" slide did nothing on my side

 4. "Todos and Tags" slide claims that
    "Todos and tags are by default hidden."
    But they are not. The default values of dslide-hide-tags and
    dslide-hide-todos are both nil.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Dslide 1.0 Feature Roadmap & RFC

[Psionic K]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

> May animations be disabled in the slides? They are not necessary most
> of the time in the real-world presentations

Reasonable.  I'll get this supported, as well as making "peel" an option.
Peeling is currently only activated on item-reveal when :inline is t.

> <down> is way too easy to use accidentally. Why not just
>    C-x k? It is not like people need to quit frequently enough to have
>    a very simple and easy-to-reach binding just for quitting

Might need a `kill-buffer-hook' but overall, seems like another better
default.  Recently I changed <up> so that it goes to the slide at point.
It makes sense to unbind <down>.

> (I'd also add SPC DEL)

What would they do?  I know SPC is often some kind of progress, but I don't
use DEL bindings enough to know them.

> does not go back to the slide being displayed

Design-wise, there's another question:  You can only see top-level
headings.  It might be necessary to show more of the tree before trying to
support this.  To support it, I need to implement `dslide-goto` at least on
slide actions.  I don't expect that soon because of changes I need to make.

> 3. For some reason, "Every Child" slide did nothing on my side

I can't think of any reason it wouldn't work.  Are you using
non-graphical?  I can imagine that if the logic selects no animation, then
no behavior is visible, but that's just a theory.

> 4 "Todos and Tags" slide claims that

🤡.  Fixed and pushed to master.  Thanks for checking.

[-- Attachment #2: Type: text/html, Size: 1906 bytes --]

Re: Dslide 1.0 Feature Roadmap & RFC

[Ihor Radchenko]

Psionic K <psionik@positron.solutions> writes:

>> (I'd also add SPC DEL)
>
> What would they do?  I know SPC is often some kind of progress, but I don't
> use DEL bindings enough to know them.

See view-mode-map. In many terminal pagers SPC is to scroll to next
screen and DEL to scroll to previous screen. Similar convention is used
in most presentation software (pdfpc, LibreImpress, etc)

>> 3. For some reason, "Every Child" slide did nothing on my side
>
> I can't think of any reason it wouldn't work.  Are you using
> non-graphical?  I can imagine that if the logic selects no animation, then
> no behavior is visible, but that's just a theory.

Graphical. And I cannot reproduce anymore. You can ignore this one.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Dslide 1.0 Feature Roadmap & RFC

[Karthik Chikmagalur]

>>> (I'd also add SPC DEL)
>>
>> What would they do?  I know SPC is often some kind of progress, but I don't
>> use DEL bindings enough to know them.
>
> See view-mode-map. In many terminal pagers SPC is to scroll to next
> screen and DEL to scroll to previous screen. Similar convention is used
> in most presentation software (pdfpc, LibreImpress, etc)

On the other hand this makes it harder to use SPC to self-insert in the
presentation.  One of the advantages of presenting from Org is that the
document can be edited live, otherwise I would export to reveal.js or
similar.

Karthik