feat: add 2 more nesting levels for toc

[regevbr]

fix: #1216
feature request: https://requarks.canny.io/wiki/p/allow-to-select-toc-depth-level (20 votes)
feature discussion at: #1931

To sum up the feature:

1. You can control (globally and per page) the nesting level of the table of contents.
2. You can control from what level, collapsing will occur (globally and per page) so that up to that level all entries will be shown and to see the rest you will need to click the toc entry.
   Check out the gif below for a quick overview.

@NGPixel and @fireundubh I would love to get any comments on the UI/UX as it is not my strong suite.

[fireundubh]

I would love to get any comments on the UI/UX as it is not my strong suite.

I've thought about this for a while. Visually, I'd prefer sliders over radio buttons, but radio buttons are functional. I don't have any functional feedback.

[fireundubh]

@NGPixel This PR has been open for a month. When can this PR be implemented?

[a96219]

@NGPixel When can this PR be implemented? I need this feature because my documents have so many directories. Thank you, if possible

[NGPixel]

It will be implemented in 3.0 update, which will include proper theming handling. I didn't want to merge something, including API changes, that would change in the following version.

[regevbr]

@NGPixel What ia the rough ETA on version 3?

[NGPixel]

Q4 2020

[mygrexit]

Is this still scheduled for 3.0 @NGPixel?

[TimoKruth]

@NGPixel this feature seams to work quite well. What can I do to help get this into a release and maybe other PRs aswell?
I would like to reduce the list of open PRs before I open any new ones that need additional attention.
Is there a way to support you at this?
Or with other words can I contribute to 3.0 in some way that helps you?

[NGPixel]

I would consider accepting this PR for 2.x as the next version still require more time. I would however want some UI changes as to not rely on 10 radio boxes, which is a bit too busy. A range slider would be more appropriate, example in 3.0:

Also, the behavior should be more in line with how 3.x will work, with a min and max value:

• min: The minimum heading that will be shown. A value of 2 would ignore h1 nodes but still show their children (if any).
• max: The maximum heading that will be expanded. Lower headers are still accessible but collapsed by default.

These changes shouldn't require much work but it would make the transition to 3.x much easier.

[TimoKruth]

These changes shouldn't require much work but it would make the transition to 3.x much easier.

If the OP doesn't react before I am done I will try to accomplish this and Push it here.
If you would have a branch that has the current v3.0-preRelease state to compare to that would be quite nice.

And if I can help you with anything on version 3.0 let me know.

btw: the current dev guideline for Mac seems broken. If I start the container, it always breaks at make because cmake is not present. I get 3 containers but the wiki never starts, just adminer is accessible. Not sure if I have done anything wrong though.
Edit: For my problem with cmake on my M1 Mac. I had to add cmake to theapt-get installpart of the Dockerfile

[TimoKruth]

I created a PR with Sliders instead feel free to have a look at #5101