Closed JoeZiminski closed 2 days ago
Super busy day today so I'll give this a full read in the next couple days. I think this seems cool. I want to think about the concerns--adding css and html means that to contribute might become more daunting for the docs rather than a nice intro into the project so I'd like to think about looking good/dev preference vs inclusivity. But I'll do a full read soon :)
Thanks @zm711, looking forward to hearing your thoughts!
Any way to fix this?
Hey @zm711, it might be through the sphinx machinery but I am not sure. This is an issue with the current live docs as well i.e. here but does not appear for the proposed custom index. I guess another benefit of the flexibility is we can directly troubleshoot such issues rather than having to work around the sphinx-gallery rendering.
Hi everyone, I think this is done from my end. The CSS / hover feature is removed, and some additional docs added to the developer documentation. We can merge as normal merge (not squash) to keep the CSS stuff in the git history in case it is useful to return to later.
@samuelgarcia @alejoe91 are you happy for this to be merged?
We can ping them again early next week. I think this is nice so let's get this merged :)
This PR introduces a potential new way to index sphinx-gallery generated pages rather than using the default sphinx-gallery pages. This follows from discussions such as #2327 #2800, where it was discussed that having more flexibility to integrate sphinx-generated tutorials and non-sphinx generated
.rst
files in the same index page would be useful. At present, what is atutorials
vs.how to
is arbitrarily fixed by how the documentation is built.The approach taken here is to
custom_tutorial_index.rst
that replicates the currenttutorials/index.rst
page generated by sphinx (both are kept on the docs for now, for comparison)..css
to replicate some of the sphinx behaviour.The documentation is available here.
Some benefits of this approach:
.rst
files in the same index page.Some drawbacks:
.css
file. This should never need to be changed, but nonetheless it is some added complexity in the docs codebase.EDITS: