Toolbar button scaling leads to hidden / overflown buttons.

[tmontes]

Context

While playing around and exploring the challenges I described in #757, I noticed that the toolbar button icons scale up and down as Mu's window size changes: nice! :) I also found out that the scaling mechanics felt non-obvious, at least to me, depending not only on the window width, but also on its height.

In my understanding, resizing the toolbar buttons has a single purpose: keeping them visible as much as possible, avoiding hidden / overflown buttons on the right hand side, as Mu's window width shrinks. Think:

• Make life easy for beginners.
• (nearly) Everything is just in your face.
• No hidden buttons.

Proposal

• Resize the toolbar buttons based on window width exclusively, going for a more "direct" sizing reaction in relation to the horizontally available space.
• Adjust the current thresholds such that all buttons are visible all the time.

Challenges:

• The rendered button width not only depends on icon size but also on the underlying label's text/wording and, naturally, font size.
• It can be difficult to account for nice looking, evenly spaced, all buttons visible, with a single common sizing threshold set.

Questions:

• Why is the current toolbar button sizing code dependent on window height? Are there cases where the vertical space is so small that gaining 10-30 pixels is worth the complexity / unnatural (to me at least) behaviour?

Pros:

• No hidden buttons.
• Near trivial implementation

Cons:

• None that I can imagine, other than the fact that on very narrow displays, even the smallest sized icons, at 32x32 pixels, may not fit in the available horizontal space (which is already the case, so no regressions here).

Parting notes

• I have a branch with such a change implemented here.
• Willing to discuss and refine the implementation and prepare a PR for review.

[ntoll]

Yeah... this was implemented ages ago and the height consideration was down to something to do with the official Raspberry Pi touch screen dimensions (the reasons why escape me at this moment in time... but I did try to just do it via the width, as you suggest, but encountered some sort of long-forgotten problem). I'm +1 for making it just width dependent.

Also, at the request of several folks, I'm going to make the button size manually configurable via the admin dialog in version 1.1. I think we could just switch off this "automatic" behaviour and just let folks define their preferred icon size themselves.

[tmontes]

Also, at the request of several folks, I'm going to make the button size manually configurable via the admin dialog in version 1.1. I think we could just switch off this "automatic" behaviour and just let folks define their preferred icon size themselves.

My thoughts:

• Beginner beginners should never need to go into the Admin dialog.
• Beginner beginners should not need to cope with hidden buttons right (again, within reasonable limits).
• I understand that other users may want to set that themselves to a size they're happy with, disabling the current auto-sizing behaviour (intermediate beginners and up? what kind of nomenclature am I creating here?) :)

With that:

• Mu default window size should display all buttons: this works nicely today once the icon sizing thresholds are adjusted.
• Reducing/increasing Mu's window width could (as it does today) scale the icons down/up per the available space.

Best of both worlds would be:

• Buttons size automatically by default.
• A setting between "auto", "large", "medium", "small" would allow users to lock the size.

Too much effort? Or, in other words, if not automatic, which size should Mu default to so as to ensure all buttons are visible by default?

[carlosperate]

Button scaling has been implemented in PR #1842 🎉