Merge with ffreyer/MakiePresentation

[ffreyer]

With https://github.com/JuliaPlots/Makie.jl/pull/1818 merged and tagged my attempt at making presentations (https://github.com/ffreyer/MakiePresentation.jl) should be working with the latest release now. With that I think it's reasonable to talk sbout merging our packages.

My goal was to do present using Makie, i.e. to have an interactive Makie window displaying the presentation. A big annoyance with that was that you couldn't really clear a figure, which is what the pr tried to achieve. It's probably still far from perfect, but for this purpose it works well enough.

On the user side my package basically looks like this:

pres = Presentation()
display(pres)

add_slide!(pres) do fig
    # create your slide as if you had a fresh, empty figure
end

add_slide!(pres, false) do fig
    # with false the previous figure does not get cleared 
    # so you can reveal or adjust existing elements
end

Internally there are two figures, one which keeps track of the window and one that has slides drawn on. The first (parent) doesn't get cleared, so it can also be used to add a background image, for example. The other (fig) gets cleared when slides demand it. Other than this I implemented some interactivity to move throuh slides, but that's it.

From a quick look at your Slide and Presentation structs I think we could replace/merge them with my Presentation struct, though it might be necessary to fix some stuff in Makie for clearing to work correctly with CairoMakie. I would like to keep the Slides empty on creation too, so users keep full control over how they look. As far as I can tell they create 3 Axis objects by default atm?

[fatteneder]

I am all in for joining forces on this :muscle:

I picked up the same idea for a presentation engine from this Zulip thread: https://julialang.zulipchat.com/#narrow/stream/228276-makie.2Ejl/topic/Makie.20Slides

I think your version is already more mature than what I hacked together here. After all, I started learning Makie.jl recently and I am not yet so familiar with all its internals. So I am very much open to adapting to your project :)

I like your embedded figure approach. This reminds me on master-slides/elements in LibreOffice, PowerPoint or Keynote. Perhaps that is the right place to put headers, footers, page numbers, etc. My approach was to give each slide a separate figure and then, when presenting, just display one figure after another. This way I avoided clearing figures in between. I also thought about making the Slide struct behave just like a figure, so that you can still use the very intuitive grid layout syntax from Makie.jl, cf. the suggestion in the link. The drawback of one-figure-for-each-slide this is that resizing or zooming in one slide (figure) does not automatically propagate the window size or zoom level to others, which makes it annoying when you move between slides. I second your idea to leave slides empty on creation. The three Axis elements I added so far were just place holders for now and we can certainly refactor all of that logic.

Let me just summarizes other things I managed to get working (somehow):

• Saving a presentation as a PDF using CairoMakie.jl and Cairo.jl.
• I got automatic line wrapping to work. However, that might be obsolete if your PR https://github.com/JuliaPlots/Makie.jl/pull/1819 gets merged into Makie.jl, which I will appreciate a lot :)
• bold and italic styled text (that was an easy one)

The last thing I was working on was to get Base.Markdown text rendering with Makie.jl going. My idea is to add custom @recipes and Layoutables/Blocks for all Markdown elements we need and then put them into a single MarkdownBox, which is just a GridLayout under the hood. This way we could make the MarkdownBox play nicely with the rest of Makie.jl. So far I started with the implementation of the Paragraph Markdown element, which is just the wrapped text and stylized fonts, and Lists (not working yet). It remains to implement Lists, Tables, Code and LaTeX. I think we could skip Images for obvious reasons. Tables could be implemented again with a Gridlayout. For LaTeX we might need support from the MathTex.jl package. For the Code element (as well as inline code) I don't have an idea yet on how to get the nice styling as you have it here on Github for example (including syntax highlighting!).

Sorry for the long reply. Let me know what you are thinking about and how we should proceed!

[ffreyer]

I'm not sure if it's a good idea to rely on MakieLayout for things like tables. Afaik whenever you add an element updates bounce back and forth between all the different elements as they try to figure out good sizes. With the just-in-time nature I have this could end up getting slow. (Because triggering size updates of elements also usually cascades down to lots of other stuff like ticks for Axis or the underlying plots in general.) I think I already had some issues with that. (I didn't check thoroughly) I was thinking if maybe we can cache layout results to avoid issues with this but I didn't look into it. (I think there's also a way to pause layout updates, maybe that would be enough?)

Some other ideas I had:

• Optionally caching slides to images and rendering those instead. This would also help a lot with speed but obviously makes slides static.
• Caching slides as images for a slide selection menu. Something like all the PowerPoint like programs have on the side in edit mode, but hidden by default. That could be used to jump to a specific slide more quickly after a presentation, to answer questions or discuss further. (Might also be a good opportunity to rework Makie.Menu when implementing this. Adding scrolling and arbitrary menu items would be neat.)

Let me know what you are thinking about and how we should proceed!

I was thinking of merging my code into this repository. I didn't intend to work on Makie presentations long term, I just wanted to experiment with it for a bit. So I'd be happy if you (or someone else) maintains it.

[fatteneder]

Regarding layouting: I can see what you mean. The Paragraph implementation I have (trying to get it to work again right now) displays some notable delay (not much, but it is there) whenever I resize the window and all the line breaks have to be recomputed, which then change the text box size and so on etc. But I think adjusting the layout dynamically to the window size is not really what we want, but instead the layout should be fixed once upon slide creation given a screen ratio. All we need to do then is to up- or down scale it if the window size is changed. So basically that goes in the direction of your idea on caching layouts -- I like it.

Optionally caching slides to images and rendering those instead. This would also help a lot with speed but obviously makes slides static.

Seems to be worth to implement anyways as a fallback in case your machine isn't that powerful. And as a very last resort one could also export a PDF and then use an external viewer.

The slide selection menu could also be combined with multiple window support (https://github.com/JuliaPlots/Makie.jl/pull/1771) in order to open a second window along the actual presentation with details for the speaker, e.g. displaying the slide menu, a timer, speaker notes, etc.

I was thinking of merging my code into this repository.

That is fine with me too :) I must say that right now I can only spend time for this on the weekends. But I will definitely be around for a while.

[fatteneder]

Regarding layouting: The lag I reported earlier seems to have come from the stdout latency and all the debug messages I printed to the console. Removing those also removed the lag. I now got the Markdown.List rendering working for which I also decided to use a GridLayout in order to group the listing symbols into one column and the actual text into another. Still no lag with about 40 elements. I should say that I am using a brand new laptop right now and this benchmarking wasn't done in an objective way.

I will implement the Table with the same approach next and then we will see if we need caching or not.

[asinghvi17]

clearing to work correctly with CairoMakie

What issues have you run into there? As I understand it the CairoMakie pipeline redraws on every display, so clearing is effectively irrelevant (since the only way one could see the result is to re-render the figure).

Also, if you don't want to use GLMakie for whatever reason, CairoMakie can be made to work with Gtk.jl (check out the CairoMakie README), so if Gtk's mouse or keyboard events could be hooked up to the Makie Screen and event structure, it would basically be feature-comparable in 2D (and some 3D, even!) with GLMakie.

[ffreyer]

What issues have you run into there?

I haven't tried yet. I'm just worried because GLMakie was/is quite a mess in that respect.