DOC: Make event handling table scrollable #24752

QuLogic · 2022-12-17T04:06:10Z

PR Summary

The existing table is too wide, and overflow is clipped, so that not all toolkits are visible.

Fixes (partially?) #24741

I also changed Nothing to *nothing* to make it clearer ~~and added a *nothing* to the macosx table for AltGr.~~

PR Checklist

Documentation and Tests

[n/a] Has pytest style unit tests (and pytest passes)
Documentation is sphinx and numpydoc compliant (the docs should build without error).
[n/a] New plotting related features are documented with examples.

Release Notes

[n/a] New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
[n/a] API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
[n/a] Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst

QuLogic · 2022-12-17T05:08:36Z

After writing this PR description, I realized we should probably mark these keys with :kbd:.

greglucas

I like this styling, and especially the :kbd: addition!

Some minor nits if you're able:

Switching between tabs the width of the columns changes and jumps around a bit, so can you fix the width of the columns relative to the maximum somehow?
Keyboard keys with a + in them show up as bold for me and are also inset a couple of points relative to the non multi-keys. Would be nice to get all of that consistent too.

greglucas · 2022-12-17T15:52:59Z

doc/users/explain/event_handling.rst

+         :kbd:`Shift`             shift
+         :kbd:`Control`           control
+         :kbd:`Alt`               alt
+         :kbd:`AltGr`             *nothing*


Are these actually nothing or are they unknown? For example, I filled out most of the macosx section and I just don't have an AltGr key, so I just had no idea what it produces :)

I don't know actually, so I've reverted it to be empty.

tacaswell

lost gtk

timhoffm · 2022-12-19T00:15:14Z

I agree that a clipped table is not feasible. However, the tabs are not very good from a usability perspective either. The table is about inconsistencies between the backends. The key information is the comparison between the backends. This is quite complicated if you can only see one backend at a time.

We should think about other alternatives, e.g. (I'm not a CSS expert) could one make a button that let's the table element expand to the right and float over the right side bar? Or maybe a button to pop it out as an overlay similar to the search field.

Side note: I find the very limited horizontal space in the pydata-sphinx-theme quite annoying. Are there no other projects that need more horizontal space from time to time? Maybe we should bring the topic back to pydata-sphinx-theme and discuss possible solutions with them.

QuLogic · 2022-12-20T06:12:44Z

Switching between tabs the width of the columns changes and jumps around a bit, so can you fix the width of the columns relative to the maximum somehow?

I tried making the columns the same width in the source, but that didn't seem to fix it in the result.

Keyboard keys with a + in them show up as bold for me and are also inset a couple of points relative to the non multi-keys. Would be nice to get all of that consistent too.

That's just how Sphinx produces them; they get nested <kbd> tags, and I guess the theme sets it up in a way that the style stacks. I would guess we should report that to pydata-sphinx-theme?

We should think about other alternatives, e.g. (I'm not a CSS expert) could one make a button that let's the table element expand to the right and float over the right side bar? Or maybe a button to pop it out as an overlay similar to the search field.

It is relatively simple to add a horizontal scroll bar to the note if it is too large. We could also have the overflow appear on hover, but I'm not sure how well that works on small screens. I think I've seen a similar thing on code blocks in places. The button idea is more complicated, as I expect it would need JavaScript to implement.

greglucas · 2022-12-20T22:08:23Z

Keyboard keys with a + in them show up as bold for me and are also inset a couple of points relative to the non multi-keys. Would be nice to get all of that consistent too.

That's just how Sphinx produces them; they get nested <kbd> tags, and I guess the theme sets it up in a way that the style stacks. I would guess we should report that to pydata-sphinx-theme?

Yeah, I think so, it definitely looks odd to me, but no need to change it here. They are better than before.

It is relatively simple to add a horizontal scroll bar to the note if it is too large.

If we are going back to the horizontal scroll bar, I think it would be nice to freeze the first column as well then. That first column is the independent variable here that we sort of need to understand everything else.

QuLogic · 2022-12-21T08:19:01Z

I believe there is a way to scroll and keep the first column, but in order to do that, we need to actually mark the first column differently. The only way to do this in reST is to make it a list-table and specify the stub-columns option. This will mark them as th instead of td.

QuLogic · 2022-12-21T09:09:24Z

This should work like that now, I believe. Unfortunately, the whole note scrolls a little bit before the first column becomes sticky, and I don't know a way to fix that. But this is probably better than before.

greglucas · 2022-12-21T14:35:25Z

I wasn't able to get it to freeze/stick the first column for me? Another thing to consider is re-ordering the items to have the more commonly used/extended toolkits up front, having QT and Tk be the first two columns I'd guess.

tacaswell · 2022-12-21T20:32:45Z

I would go with the order [tk, qt, macosx, webagg, gtk, wxpython].

QuLogic · 2022-12-22T03:53:01Z

I wasn't able to get it to freeze/stick the first column for me?

Ah, oops, I missed copying something something from build back to the source.

The existing table is too wide, and overflow is clipped, so that not all toolkits are visible. Also, wrap all the entered keys in `:kbd:`, and re-sort the columns. Fixes matplotlib#24741

QuLogic · 2022-12-22T04:35:19Z

I moved the table into a div with a wide-table class instead of relying on the note's div. This means the CSS may be reused for other places if we have any by wrapping the table in a container (but I believe there aren't any other places.)

Also reordered the columns.

outdated

tacaswell · 2022-12-22T20:35:20Z

https://output.circle-artifacts.com/output/job/5be4acad-7b17-47d1-844a-10e601728765/artifacts/0/doc/build/html/users/explain/event_handling.html#event-connections is the resulting table.

QuLogic added the Documentation label Dec 17, 2022

QuLogic force-pushed the event-handling-tabs branch from 36b0e5b to 0a4b07e Compare December 17, 2022 05:20

greglucas reviewed Dec 17, 2022

View reviewed changes

tacaswell modified the milestones: v3.8.0, v3.7.0 Dec 18, 2022

tacaswell previously requested changes Dec 18, 2022

View reviewed changes

QuLogic force-pushed the event-handling-tabs branch from 0a4b07e to 5eb62a6 Compare December 21, 2022 09:08

DOC: Make event handling table scrollable

542f325

The existing table is too wide, and overflow is clipped, so that not all toolkits are visible. Also, wrap all the entered keys in `:kbd:`, and re-sort the columns. Fixes matplotlib#24741

QuLogic force-pushed the event-handling-tabs branch from 5eb62a6 to 542f325 Compare December 22, 2022 04:26

tacaswell approved these changes Dec 22, 2022

View reviewed changes

tacaswell merged commit b62376c into matplotlib:main Dec 22, 2022

QuLogic deleted the event-handling-tabs branch December 22, 2022 20:36

QuLogic changed the title ~~DOC: Change event handling table into a tab set~~ DOC: Make event handling table scrollable Dec 22, 2022

Uh oh!

DOC: Make event handling table scrollable #24752

DOC: Make event handling table scrollable #24752

Uh oh!

Conversation

QuLogic commented Dec 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

PR Checklist

Uh oh!

QuLogic commented Dec 17, 2022

Uh oh!

greglucas left a comment

Choose a reason for hiding this comment

Uh oh!

greglucas Dec 17, 2022

Choose a reason for hiding this comment

Uh oh!

QuLogic Dec 22, 2022

Choose a reason for hiding this comment

Uh oh!

tacaswell left a comment

Choose a reason for hiding this comment

Uh oh!

timhoffm commented Dec 19, 2022

Uh oh!

QuLogic commented Dec 20, 2022

Uh oh!

greglucas commented Dec 20, 2022

Uh oh!

QuLogic commented Dec 21, 2022

Uh oh!

QuLogic commented Dec 21, 2022

Uh oh!

greglucas commented Dec 21, 2022

Uh oh!

tacaswell commented Dec 21, 2022

Uh oh!

QuLogic commented Dec 22, 2022

Uh oh!

QuLogic commented Dec 22, 2022

Uh oh!

tacaswell commented Dec 22, 2022

Uh oh!

Uh oh!

QuLogic commented Dec 17, 2022 •

edited

Loading