Feature request - Sliding panes

[VarLad]

Hey! It would be nice if instead of going through multiple pages, users could have multiple panes, with a way to keep track of them.
Essentially something like this:
https://lorenzoh.github.io/Pollen.jl/dev/Pollen@dev/doc/docs/tutorials/setup.md.html?id=Pollen@dev/ref/Pollen.servedocs&id=Pollen@dev/ref/Pollen.PollenPlugin&id=Pollen@dev/ref/Pollen.setup_docs_branches&focus=0

(you need to toggle "Opened Panes" in the left to enable the panes feature)

Assuming it opens, opening links open a new pane in the right.
In the left-most, we have an index and a list of opened panes.
I think such a feature makes sense for the "forest" design.

Do tell me what you think!

[kokic]

Certainly, I do know this "panel" style.

In fact, before I decided to work on kodama, I observed many visible bidirectional linking style websites / applications. In the end, I imitated Forest — partly because it was simple enough that I could quickly get a usable prototype.

Beyond that, I’ve also been considering the usability of website features across different screen sizes (as you can see, on smaller devices, Forest’s page directory doesn’t actually appear, largely because it lacks a suitable placement). Lastly, there’s the matter of JavaScript — many page effects aren’t just visual, they also include practically functional features, but currently, most of these effects require JavaScript to work (I don’t dislike using JavaScript, but minimizing its use does have some practical benefits).

Overall, I will seriously consider supporting "panels". Ideally, I’d like it to be implemented as a theme, meaning users could choose whether to adopt these specially adjusted layouts for features like "panels". However, this feature may not arrive soon, because there aren’t many reference examples showing how to organically combine Forest and "panels". If you (or anyone else) have any good ideas, it would greatly influence the implementation progress and also increase the likelihood of others submitting PRs for it.

[VarLad]

However, this feature may not arrive soon, because there aren’t many reference examples showing how to organically combine Forest and "panels".

Does the above posted link act as a good reference for a combination of forest and "panels"?
I think the design of it is pretty reasonable, unless you have some complains. Unfortunately its only for desktop for now.

A sidebar in the left, and panels in the right. The sidebar has:

• Index
• Search through the entire forest
• List of opened panels, which user can close.

In the right you have the opened panels.

• Clicking on a link opens a new panel in the right of the existing panel.
• When there are too many panels to show on the screen, they are stacked by name.
• The user can slide through them horizontally.
• If a link to an already opened panel is clicked, it should go back to that panel.

Here's an example:

pollen2.webm

[VarLad]

Ah, there is an issue of what to do with the table of contents on every pane 🤔
I think we can have a transparent, collapsible, interactive table of contents on the top right of every panel like this:

toc.webm

No need to copy the design of ToC here, but the idea of making it collapsible and transparent, that would be nice.

[VarLad]

Do tell me what you think :)

[VarLad]

Lastly, there’s the matter of JavaScript — many page effects aren’t just visual, they also include practically functional features, but currently, most of these effects require JavaScript to work (I don’t dislike using JavaScript, but minimizing its use does have some practical benefits).

Regarding this, how about using HTMX to handle interactivity? Underneath it compiles down to JS, of course, but I think your point is about not using JS in code, and using Rust as much as possible? If so, I think HTMX can work in the same way you handle HTML.

[kokic]

Do tell me what you think :)

Sorry for the delayed reply, I've been sick recently. I will consider the implementation of the "panels" feature, but as I mentioned before, this will have to wait until the theme functionality is complete. Additionally, regarding the "collapsible and transparent TOC," the same applies—these effects will be available in the future as user-selectable themes.

[kokic]

Lastly, there’s the matter of JavaScript — many page effects aren’t just visual, they also include practically functional features, but currently, most of these effects require JavaScript to work (I don’t dislike using JavaScript, but minimizing its use does have some practical benefits).

Regarding this, how about using HTMX to handle interactivity? Underneath it compiles down to JS, of course, but I think your point is about not using JS in code, and using Rust as much as possible? If so, I think HTMX can work in the same way you handle HTML.

No, what I mean is that JavaScript can be used, but only when necessary.