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

Show TOC from root index.html on left sidebar #221

Closed
jrbourbeau opened this issue Jul 2, 2020 · 26 comments
Closed

Show TOC from root index.html on left sidebar #221

jrbourbeau opened this issue Jul 2, 2020 · 26 comments

Comments

@jrbourbeau
Copy link

I'd like to show the TOC for the root page (index.html) on the left sidebar and was wondering if it's currently possible to do so. Today the sphinx TOC appears on the left sidebar for index.html pages that are in subdirectories, but not the root index.html page.

├── index.rst        <-- TOC not in left sidebar
└── inner_section
    ├── index.rst    <--- TOC is in left sidebar
    ├── ...
    └── ...

As an example, see the pydata-sphinx-theme documentation page:

@choldgraf
Copy link
Collaborator

just to clarify - do you mean in addition to the links at the top, or instead of the links at the top?

@jrbourbeau
Copy link
Author

In addition to the links at the top. I was envisioning a more detailed TOC on the left sidebar, e.g. :maxdepth: 2, but still having the links at the top like all the other pages.

@jorisvandenbossche
Copy link
Member

Today the sphinx TOC appears on the left sidebar for index.html pages that are in subdirectories, but not the root index.html page.

That is because for the root index.html, this TOC is actually already shown, but in the header.

This theme basically tries to look at the global toctree of the full sphinx site, and the puts the first level in the top header bar, and the second (+ potentially third) level in the left sidebar.

There are variants possible where all levels of navigation are put in the left sidebar, see eg #90

@jorisvandenbossche
Copy link
Member

In addition to the links at the top. I was envisioning a more detailed TOC on the left sidebar, e.g. :maxdepth: 2, but still having the links at the top like all the other pages.

But so for the root index.html, which more detailed TOC are you thinking of?
Eg for https://pydata-sphinx-theme.readthedocs.io/en/latest/index.html, there is no more detailed TOC for the home page. There is only a more detailed TOC if you choose one of the top-level pages (on the root index.html, none of the first-level navigation items are active, so we can't choose which second-level navigation items to show)

A more concrete example would probably help to try to clarify what you mean or want to achieve.

@choldgraf
Copy link
Collaborator

I think it could be beneficial to have top-level links there only for the landing page, just to avoid having that kinda awkward white-space?

Note that this will be quite easy to special-case for the master_doc page if #219 lands.

@jorisvandenbossche
Copy link
Member

I think it could be beneficial to have top-level links there only for the landing page

But which top-level links? Repeat the ones of the header bar?
That is a possibility, but might also give a strange duplication?

To be clear, I fully agree the home page right now is not looking good with the empty side bar, but I think a more custom design might be the better solution (-> #146)

@choldgraf
Copy link
Collaborator

Repeat the ones of the header bar?

yeah that's what I had in mind. I agree it'd be a bit weird to duplicate them though

@jpmckinney
Copy link
Contributor

I don't think it makes sense to repeat navigation.

To fill the space, users might want to configure html_sidebars to display some homepage-specific content instead (e.g. the organization behind the project, sponsors, community links, whatever).

Alternately, the homepage might be fuller width.

@choldgraf
Copy link
Collaborator

@jpmckinney agreed - I think this issue came up before the html_sidebars was supported, but now that it is perhaps this is less of an issue. @jrbourbeau what do you think?

@jonnew
Copy link

jonnew commented Jul 25, 2021

I would like to have a left side bar on the top level page to show other top level pages that are not master_doc/index.html. For instance, I have a FAQ and contact pages. Making an entire top-level "About" entry in the nav-bar for those two pages feels kinda strange. I would rather have the ability to link them in the side bar of the main page. Although, this might be a different issue as I don't want to repeat what is in the top bar on the side.

@drammock
Copy link
Collaborator

@jonnew have a look at what MNE-Python does: the html_sidebars configuration (here) lets us specify a couple items (the custom one is here) that only show up on the homepage's left sidebar; other pages get the default TOC in the left sidebar.

@jonnew
Copy link

jonnew commented Jul 27, 2021

@drammock That's exactly right. Thank you!

@maximlt
Copy link
Contributor

maximlt commented Dec 24, 2021

Looks like we've managed to achieve what the OP wanted on one of our websites (https://holoviews.org/index.html).

image

And when I see it in action I think it's a better default than the empty sidebar. It also allows to get to a specific page more quickly (by expanding an item).

I would actually like to replicate that on each one of our sites, the problem is that I really have no clue how the TOC ended up being displayed in the sidebar on this site 🙃

@choldgraf
Copy link
Collaborator

I just realized that doing this would be very simple, so gave it a quick shot in #536

@damianavila
Copy link
Collaborator

Interesting related comment from another issue: #536 (comment)

@choldgraf
Copy link
Collaborator

Just a note that if our main concern is that landing pages of sites look "wrong" because of all the whitespace to the left, another approach is that we could remove the left sidebar entirely on landing pages. The main problem with this is that the search bar defaults to the left. However, we could change the default to be in the navbar instead of the left sidebar. In this case, if there were no sidebar items to display, then the sidebar would disappear entirely and the content would center.

There is a good amount of precedence for this. For example, the following topbar-based themes have their search in the topbar by default:

Docasaurus:

image

Material mkdocs:

image

GitBook:

image

@damianavila
Copy link
Collaborator

Another interesting comment from @jbednar: #536 (comment)

@damianavila
Copy link
Collaborator

There is a good amount of precedence for this. For example, the following topbar-based themes have their search in the topbar by default:

I was going to suggest the same... It is always "weird" to me to not see the search box in the navbar and that is maybe because that pattern is pretty well extended and predominant by now.

@maximlt
Copy link
Contributor

maximlt commented Jan 14, 2022

+1 for having the search box in the navbar, like in the examples shown above and like on Facebook or Linkedin.

@jorisvandenbossche
Copy link
Member

Yes, I think that indeed moving the search box might make sense.

Exploring some more sites:

The original layout if this theme was based on the bootstrap docs site, as you can see here (https://getbootstrap.com/docs/4.1/getting-started/introduction/):

image

However, in their latest version, they actually also moved the search box ((https://getbootstrap.com/docs/5.1/getting-started/introduction/):

image

It is now in the second navbar (when scrolling down, it's only this second navbar that stays visible):

image

Other documentation sites I often check for inspiration, and also have it in the top navbar, are Docker (https://docs.docker.com/get-started/):

image

and Tensorflow (https://www.tensorflow.org/tutorials):

image

One other example of a documentation framework with the search box in the sidebar is Docsy (https://www.docsy.dev/docs/examples/):

image

But here the search box stays on top and only the navigation tree scrolls (xref #560):

image

leycec added a commit to beartype/beartype that referenced this issue Feb 9, 2023
This commit is the next in a commit chain coercing our monolithic
`README.rst` documentation onto Read the Docs (RTD), en-route to
resolving issue #203 kindly submitted by @LittleBigGene (AKA the dynamo
of the cell). Specifically, this commit:

* Successfully extracts our FAQ into a new `faq` subdocument.
* Circumvents upstream's long-standing issue with empty left sidebars at
  pydata/pydata-sphinx-theme#221 via the requisite template hack that we
  now riskily embed in our Sphinx tree. Hang on, folks! The ride ahead
  is perilous, indeed.

(*Discursive cursive discourse is the discus' course!*)
leycec added a commit to beartype/beartype that referenced this issue Feb 14, 2023
This commit is the next in a commit chain coercing our monolithic
`README.rst` documentation onto Read the Docs (RTD), en-route to
resolving issue #203 kindly submitted by @LittleBigGene (AKA the dynamo
of the cell). Specifically, this commit circumvents upstream theme
issues pydata/pydata-sphinx-theme#90 and pydata/pydata-sphinx-theme#221
with the "standard" `_templates/sidebar-nav-bs.html` hack shamelessly
copy-pasted into literally *every* project requiring that theme. This
includes @beartype, because why not spew boilerplate that nobody
understands everywhere? (*Intimate intimations of illegitimate legerdemain!*)
leycec added a commit to beartype/beartype that referenced this issue Feb 15, 2023
This commit is the next in a commit chain coercing our monolithic
`README.rst` documentation onto Read the Docs (RTD), en-route to
resolving issue #203 kindly submitted by @LittleBigGene (AKA the dynamo
of the cell). Specifically, this commit circumvents upstream theme
issues pydata/pydata-sphinx-theme#90, pydata/pydata-sphinx-theme#221,
and pydata/pydata-sphinx-theme#1181 with the "standard"
`_templates/sidebar-nav-bs.html` hack shamelessly copy-pasted into
literally *every* project requiring that theme. This includes @beartype,
because why not spew boilerplate that nobody understands everywhere?
Sadly, doing so now requires pinning to a maximum obsolete version of
this theme that will also surely die soon. And this is why I facepalm.
(*Illogical ontological topology!*)
leycec added a commit to beartype/beartype that referenced this issue Apr 8, 2023
This minor release delivers pulse-quickening support for **pandera
(pandas) type hints,** **PEP 484,** **PEP 585**, **PEP 591**, **PEP
647**, **PEP 3119**, and **pseudo-callables.**

This minor release resolves **12 issues** and merges **2 pull
requests.** But first, a quiet word from our wondrous sponsors. They are
monocled QA wizards who serve justice while crushing bugs for humanity.
High fives, please!

## Beartype Sponsors

* [**ZeroGuard:** The Modern Threat Hunting
  Platform](https://zeroguard.com). *All the signals, All the time.*

Thunderous applause echoes through the cavernous confines of the Bear
Den. 👏 🐻‍❄️ 👏

And now... the moment we've waited for. A heinous display of plaintext
that assaults all five senses simultaneously.

## Compatibility Added

* **Pandera (pandas) type hints** (i.e., ad-hoc PEP-noncompliant type
  hints validating pandas `DataFrame` objects, produced by subscripting
  factories published by the `pandera.typing` subpackage and validated
  *only* by user-defined callables decorated by the ad-hoc
  PEP-noncompliant `@pandera.check_types` runtime type-checking
  decorator), resolving feature request #227 kindly submitted by
  @ulfaslakprecis (Ulf Aslak) the Big Boss Typer. @beartype now:
  * Transparently supports pandera's PEP-noncompliant
    `@pandera.check_types` decorator for deeply runtime type-checking
    arbitrary pandas objects.
  * *Always* performs a rudimentary `O(1)` `isinstance()`-based
    type-check for each Pandera type hint. Doing so substantially
    improves usability in common use cases, including:
    * Callables annotated by one or more pandera type hints that are
      correctly decorated by @beartype but incorrectly *not* decorated
      by the pandera-specific `@pandera.check_types` decorator.
    * (Data)classes annotated by one or more pandera type hints.
    * Pandera type hints passed as the second argument to
      statement-level @beartype type-checkers – including:
      * `beartype.door.is_bearable()`.
      * `beartype.door.die_if_unbearable()`.
  * Implements a non-trivial trie data structure to efficiently
    detect all type hints produced by subscriptable factories in the
    `pandera.typing` submodule. Let us pretend this never happened,
    @ulfaslakprecis.
* **PEP 484- and 585-compliant generator constraints.** This release
  relaxes prior constraints erroneously imposed by @beartype
  prohibiting both asynchronous and synchronous generator callables from
  being annotated as returning unsubscripted standard abstract base
  classes (ABCs) defined by the `collections.abc` module. Now, @beartype
  permits:
  * Asynchronous generator callables to be annotated as returning the
    unsubscripted `collections.abc.AsyncGenerator` type.
  * Synchronous generator callables to be annotated as returning the
    unsubscripted `collections.abc.Generator` type.
* **PEP 591** (i.e., `typing.Final[...]` type hints), partially
  resolving issue #223 kindly submitted by the acronym known only as
  @JWCS (Jude). @beartype now trivially reduces *all*
  `typing.Final[{hint}]` type hints to merely `{hint}` (e.g.,
  `typing.Final[int]` to `int`). In other words, @beartype no longer
  raises exceptions when confronted with final type hints and instead at
  least tries to do the right thing. This still isn't *quite* what
  everyone wants @beartype to do here; ideally, @beartype should also
  raise exceptions on detecting attempts to redefine instance and class
  variables annotated as `Final[...]`. Doing so is *definitely* feasible
  and exactly what @beartype should *eventually* do – but also
  non-trivial, because whatever @beartype *eventually* does needs to
  preserve compatibility with all implementations of the `@dataclass`
  decorator across all versions of Python now and forever. Cue that
  head-throbbing migraine. It's comin'! Oh, I can feel it!
* **PEP 647** (i.e., `typing.TypeGuard[...] type hints`), resolving
  feature request #221 kindly submitted by Google X researcher
  extraordinaire @patrick-kidger. @beartype now trivially reduces *all*
  `typing.TypeGuard[...]` type hints to the builtin `bool` type.

## Compatibility Improved

* **PEP 3119.** @beartype now detects both
  **non-isinstanceable classes** (i.e., classes whose metaclasses define
  PEP 3119-compliant `__instancecheck__()` dunder methods
  unconditionally raising `TypeError` exceptions) and
  **non-issubclassable classes** (i.e., classes whose metaclasses define
  PEP 3119-compliant `__subclasscheck__()` dunder methods
  unconditionally raising `TypeError` exceptions) more narrowly for
  safety, resolving issue #220 kindly submitted by *ex*traordinary
  Google X researcher @patrick-kidger (Patrick Kidger). Notably,
  @beartype now *only* accepts `TypeError` exceptions as connoting
  non-isinstanceability and non-issubclassability. Previously, @beartype
  broadly treated any class raising any exception whatsoever when passed
  as the second parameter to `isinstance()` and `issubclass()` as
  non-isinstanceable and non-issubclassable. Sadly, doing so erroneously
  raises false positives for isinstanceable and issubclassable
  metaclasses that have yet to be fully "initialized" at the early time
  the `@beartype` decorator performs this detection.

## Features Added

* **Pseudo-callable monkey-patching support.** `@beartype` now supports
  **pseudo-callables** (i.e., otherwise uncallable objects masquerading
  as callable by defining the `__call__()` dunder method), resolving
  feature request #211 kindly submitted by Google X typing guru
  @patrick-kidger (Patrick Kidger). When passed a pseudo-callable whose
  `__call__()` method is annotated by one or more type hints,
  `@beartype` runtime type-checks that method in the standard way.

## Documentation Revised

* **Literally everything,** also known as the release that migrated
  `README.rst` -> [Read the Docs
  (RtD)](https://beartype.readthedocs.io), resolving both issue #203
  kindly submitted by @LittleBigGene (AKA the dynamo of the cell) and
  ancient issue #8 kindly submitted by @felix-hilden (AKA the Finnish
  computer vision art genius that really made all of this possible).
  Readable documentation slowly emerges from the primordial soup of
  @beartype's shameless past for which we cannot be blamed. @leycec was
  young and "spirited" back then. Specifically, this release:
  * Coerces our prior monolithic slab of unreadable `README.rst`
    documentation into a website graciously hosted by Read the Docs
    (RtD) subdividing that prior documentation into well-structured
    pages, resolving issue #203 kindly submitted by @LittleBigGene (AKA
    the dynamo of the cell).
  * Documents *most* previously undocumented public APIs in the
    @beartype codebase. Although a handful of public APIs remain
    undocumented (notably, the `beartype.peps` submodule), these
    undocumented APIs are assumed to either be sufficiently unpopular or
    non-useful to warrant investing additional scarce resources here.
  * Updates our installation instructions to note @beartype's recent
    availability as official packages in the official package
    repositories of various Linux distributions. Truly, this can only be
    the final mark of pride. These include:
    * Gentoo Linux's Portage tree.
    * Arch Linux's Arch User Repository (AUR).
  * Improves the Python code sample embedded in the ["Are We on the
    Worst Timeline?" subsection of our **Beartype Errors**
    chapter](https://beartype.readthedocs.io/en/latest/api_roar/#are-we-on-the-worst-timeline).
    Thanks to @JWCS for their related pull request (PR) #210, which
    strongly inspired this bald-faced improvement to the usability of
    our `beartype.typing` API.
  * Circumvents multiple long-standing upstream issues in the PyData
    Sphinx theme regarding empty left sidebars via the requisite
    `_templates/sidebar-nav-bs.html` template hack shamelessly
    copy-pasted into literally *every* project requiring this theme.
    This includes @beartype, because why not spew boilerplate that
    nobody understands everywhere? Sadly, doing so requires pinning to a
    maximum obsolete version of this theme that will surely die soon.
    And this is why I facepalm. These issues include:
    * pydata/pydata-sphinx-theme#90.
    * pydata/pydata-sphinx-theme#221.
    * pydata/pydata-sphinx-theme#1181.
  * Truncates our `README.rst` documentation to a placeholder stub that
    just directs everyone to RtD instead.
  * Improves `linecache` integration commentary. Specifically, a pull
    request by @faangbait (AKA the little-known third member of Daft
    Punk) improves internal commentary in our private
    `beartype._util.func.utilfuncmake.make_func()` factory function
    responsible for dynamically synthesizing new in-memory functions
    on-the-fly. Our suspicious usage of `None` as the second item of
    tuples added as values to the standard `linecache.cache` global
    dictionary has now been documented. Thanks so much for this
    stupendous contribution, @faangbait!

## Tests Improved

* **Mypy integration.** This release improves our `test_pep561_mypy()`
  integration test to intentionally ignore unhelpful non-fatal warnings
  improperly emitted by mypy (which encourage usage of
  `typing_extensions`, oddly enough).
* **Sphinx integration.** This release resolves multiple intersecting
  issues involving integration testing of Sphinx + @beartype, including:
  * `test_beartype_in_sphinx()` h0tfix is h0t. This release generalizes
    our test-specific `test_beartype_in_sphinx()` integration test to
    support arbitrary versions of Sphinx, resolving issue #209 kindly
    submitted by @danigm the sun-loving Málaga resident who frolics in
    the sea that Canadians everywhere are openly jealous of.
    Specifically, this release fundamentally refactors this integration
    test to fork a new Python interpreter as a subprocess of the current
    `pytest` process running the `sphinx-build` command.
  * A Python 3.7-specific failure in our continuous integration (CI)
    workflow caused by Sphinx attempting to call deprecated
    functionality of the third-party `pkg_resources` package. This
    release simply avoids installing Sphinx entirely under Python 3.7;
    although admittedly crude, it's unclear how else @beartype could
    possibly resolve this. Since Python 3.7 has almost hit its official
    End-Of-Life (EOL) and thus increasingly poses a security concern,
    this is hardly the worst resolution ever. Really! Believe what we're
    saying.

Break nothing! It's the @beartype way. This is why @leycec cries like a
mewling cat with no milk. (*Thrilling chills spill towards an untoward ontology!*)
@dstansby
Copy link
Contributor

Another reason to have the sidebar on the index page is on readthedocs - the sidebar needs to be present to show the version switcher, so by default the readthedocs version switcher isn't currently shown on the root page 😢

@robmoss
Copy link

robmoss commented Apr 18, 2024

Another reason to have the sidebar on the index page is on readthedocs - the sidebar needs to be present to show the version switcher, so by default the readthedocs version switcher isn't currently shown on the root page 😢

This is my one and only use case for this feature.

Edit: I've made a custom template based on toctree.html, where I pass startdepth=0 and maxdepth=1, and add it to the 'index' entry in the html_sidebars dictionary. My one reservation is keeping this template consistent with future versions of the pydata-sphinx theme.

@drammock
Copy link
Collaborator

I think this can be closed now:

@maximlt
Copy link
Contributor

maximlt commented Dec 12, 2024

@drammock how does one display the TOC on the root index in the left sidebar with the latest version of the theme?

@drammock
Copy link
Collaborator

@drammock how does one display the TOC on the root index in the left sidebar with the latest version of the theme?

I would consider that wontfix, or at least very low priority to add/support.
Adding layout variants w/r/t the TOC has been discussed elsewhere (as mentioned near the start of this thread), and although we recognize it would be great to offer, so far none of the maintainers have said "let's go for it", I think because:

  1. it's a big lift in terms of added complexity, which has long-term maintenance/support commitments that nobody on the maintainer team is comfortable with yet, because
  2. there are lots of other fixes/enhancements that are higher priority for us (especially w/r/t accessibility), and
  3. there are some really nice alternative themes that are designed with the root TOC in the left sidebar (sphinx book theme and furo are the top two that we recommend, e.g. here)

@maximlt
Copy link
Contributor

maximlt commented Dec 14, 2024

Ok thanks for the answer. I still think that'd be a useful feature, I use it quite a lot when going on a website and expanding the items in the side bar to go directly to the documentation page I'm after.

For reference, we're replacing the default sidebar template with this one to obtain this behavior:

<!-- Adapted from sidebar-nav-bs.html (1.15.2) with the following changes

  - Commented out the tag that adds the "Section Navigation" title
  - Call generate_toctree_html with startdepth=0

Please update this file when required when bumping the max pin of pydata-sphinx-theme.
-->

{# Displays the TOC-subtree for pages nested under the currently active top-level TOCtree element. #}
<nav class="bd-docs-nav bd-links"
      aria-label="{{ _('Section Navigation') }}">
  <!-- <p class="bd-links__title" role="heading" aria-level="1">{{ _("Section Navigation") }}</p> -->
  <div class="bd-toc-item navbar-nav">
    {{- generate_toctree_html(
      "sidebar",
      startdepth=0,
      show_nav_level=theme_show_nav_level | int,
      maxdepth=theme_navigation_depth | int,
      collapse=theme_collapse_navigation | tobool,
      includehidden=theme_sidebar_includehidden | tobool,
      titles_only=True
      )
    -}}
  </div>
</nav>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants