Responsive document toolbar

[3coins]

References

This PR fixes the issue #10595

Code changes

Toolbar class has a new default button and a popup. The resize handler is added which keeps track of widths of items and moves them to the popup if the cumulative width increases toolbar width. Alternatively, if toolbar width is big enough to accommodate any widgets in the popup, they are moved back to the toolbar.

User-facing changes

Toolbar has a new default button and a popup that stores items that don't fit in the toolbar when the toolbar is resized.

Backwards-incompatible changes

None

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[krassowski]

My slight preference would be to keep the items that indicate state (kernel name, kernel busy indicator, debugger toggle, cell type switch) visible as long as possible (hide them last). Would this be feasible to implement? What do others think?

[3coins]

My slight preference would be to keep the items that indicate state (kernel name, kernel busy indicator, debugger toggle, cell type switch) visible as long as possible (hide them last). Would this be feasible to implement? What do others think?

I had a slight inclination towards that idea while implementing this. It is definitely possible to implement, however I feel that it might increase the complexity of the code quite a bit without providing any huge benefit to users. Also, this code is quite general at the moment that it works for all toolbars, so it will require some kind of configuration added for all toolbars to define elements to hide last. Would love to hear feedback from others.

[fcollonval]

We definitely should extend the metadata of toolbar items to add the ability to select which element should be hidden first.

I see two paths:

• Simple approach: define a primary and a secondary groups of items. The secondary groups are hidden first starting from the most rightful element. Then the primary group is hidden from the most rightful element.
• Advanced approach: there is a ranking of visibility on all items. That ranking is used to determine in which order element are hidden.

I would favor the first approach as visibility importance will definitely depends on the user taste; so it should be customizable (don't worry about that here) and I think a simple primary / secondary approach will be easier to grasp than figure out the ranking of all items.

cc @ellisonbg

[ellisonbg]

@fcollonval I do think that over time we need to tackle this question of additional metadata for toolbar items to help prioritze when different items get moved to the overflow toolbar. Adding another option to the list:

• Introduce semantic sections for toolbar items and move the entire section the overflow menu at once. I have a seen a number of applications use this approach very effectively. In particular Google Docs uses a triple dot icon with an overflow toolbar in the right-most position in the toolbar. As the width decreases, groups are moved to the overflow menu starting from the right-most group and moving left.

Full width:

A few groups moved to the overflow:

[ellisonbg]

At the same time, I believe this PR is enough of an improvement, that we should merge it and iterate further to add sections and/or other metadata.

[blink1073]

Merge and iterate sounds good, thank you!

[welcome]

Congrats on your first merged pull request in this project! 🎉

Thank you for contributing, we are very proud of you! ❤️

[3coins]

We definitely should extend the metadata of toolbar items to add the ability to select which element should be hidden first.

I see two paths:

• Simple approach: define a primary and a secondary groups of items. The secondary groups are hidden first starting from the most rightful element. Then the primary group is hidden from the most rightful element.
• Advanced approach: there is a ranking of visibility on all items. That ranking is used to determine in which order element are hidden.

I would favor the first approach as visibility importance will definitely depends on the user taste; so it should be customizable (don't worry about that here) and I think a simple primary / secondary approach will be easier to grasp than figure out the ranking of all items.

cc @ellisonbg

@krassowski @fcollonval Opened a new PR for further updates to responsive toolbar.