✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: fe60113. Link to the linter CI: here}

Why configuring secondary_sidebar_items like this?

For this option when specifying a dictionary we need to use glob-style patterns and are not allowed to use multiple wild cards. Hence I traversed the directory to configure each document individually. Not sure if there is a better approach.

Why registering to the "build-finished" event?

• "builder-inited": With this we need to tweak the rst to add some metadata, and then create components that react to this metadata and do something. This can be too complicated.
• "html-page-context": First I'm not good at dealing with the docutils document tree. On the other hand, sphinx-gallery does register some functions to the "build-finished" event. Relevant or not, from my perspective it is better to tweak after everything else is set.

I may not explain in detail what sphinxext/move_gallery_links.py is doing because I've already written comments and the code is relatively easy to understand. But feel free to leave comments if there is anything I should clarify.

Why modifying README.txt?

Essentially I just need some text there. Without the text there will be a strange vertical spacing between the first and second level headings which I'm not sure where it comes from.

I like the location of the source links in the right-hand side panel.

Here is suggestion to improve the style of the links:

.sidebar-secondary-item a svg {
  margin-right: 0.5em;
}

to get:

instead of currently:

While I overall like the results, I am not a big fan of having to maintain our own HTML post-processor to move the source links at the right place.

I agree that it's a pragmatic, short-term way to move forward without having to wait for changes upstream, but in the long term, I would prefer to collaborate with sphinx-gallery maintainers to make sphinx-gallery flexible enough to have those links inserted at the right location of the pydata theme either by default or via a configuration option.

Could you please open an issue on their repo to discuss this possibility?

@adrinjalali @ogrisel Thanks for your review! I've added/updated some comments, please check if those are good enough.

.sidebar-secondary-item a svg { margin-right: 0.5em; }

Thanks for catching this. After rechecking the other pydata-sphinx-theme components I found that they have a leading space in the text instead of using margin, so I updated to be consistent with their approach.

I agree that it's a pragmatic, short-term way to move forward without having to wait for changes upstream, but in the long term, I would prefer to collaborate with sphinx-gallery maintainers to make sphinx-gallery flexible enough to have those links inserted at the right location of the pydata theme either by default or via a configuration option. Could you please open an issue on their repo to discuss this possibility?

The secondary sidebar is not a shared feature of all sphinx themes, and the classes and structures may differ a lot, so I may need to think more on how to describe the issue. Regardless I will link to this PR when opening the issue.

Given the popularity and correlated adoptions of sphinx-gallery and the pydata sphinx theme, maybe it could make sense to add a pydata theme specific config option to sphinx-gallery?

Yes you're right. A configuration option to hide (remove) the top note and the footer is clearly possible. As for the sidebar components, it might be possible for sphinx-gallery to expose some API that allows people to easily create such components, or directly implement the components and somehow ship them with the extension and to allow pydata-sphinx-theme to discover them. I will try to formulate these thoughts upstream ASAP.

Awesome, so I think we can put this on hold for now and see how things go on the upstream side?

So I've opened sphinx-gallery/sphinx-gallery#1258, please let me know if there's anything I should add or you can directly comment in that issue.

Awesome, so I think we can put this on hold for now and see how things go on the upstream side?

Since this PR is targeting the new_web_theme branch, I am fine with merging so as to get a more representative HTML previews in other PRs targeting the same feature branch.

Then we can decide prior to merging new_web_theme to main whether or not we want to wait for the upstream discussion to settle.

I'd be okay with that, I like how this looks.