WIP: Toolbar icon/font resize improvements.

[tmontes]

Working towards addressing #758.

Challenges:

• Different languages lead to different width buttons because button labels force them to become wider.
• Different platforms use different fonts / font rendering engines that may lead to slight x-platform variations.

Current status:

• Does not address the per-language threshold: from playing around with it I feel it should.
• The per-platform details can (and should) probably be avoided to avoid unnecessarily complex code.
• The non-automatic, user selectable toolbar icon size is not implemented yet.

What I'll do next:

• Implement a per-language threshold and request review and merge.
• Remaining capabilities to be addressed in a follow-up PR.

[tmontes]

WARNING: Crazy thoughts ahead

Thinking about possible solutions to language-dependent window width to icon size thresholds, I came up with a horrible (and beautiful?) idea. I'm sharing it here to see what others think of it. :)

Like I commented above, I really feel that for a nice and reasonably polished UX, the window width thresholds that establish when toolbar icons should be displayed in small/medium/large sizes should vary with the UI language: for example, there is a huge, >100px difference in DE vs ZH, for example, with EN and PT being somewhere in between, and FR being ~halfway between EN/PT and DE.

Textbook

A possible "textbook" solution would be creating a dict with per-language thresholds where, much like UI languages, the default would match EN. Something like this:

ICON_SIZE_WIN_WIDTH_MAX = {
  # (small, medium) window width tuples
  # window widths < small only support small icons
  # window widths < medium support medium icons
  # wider windows support large icons
  'zh': (930, 1200),
  'en': (960, 1200),
  'pt': (960, 1200),
  'fr': (1020, 1240),
  'de': (1050, 1280),
  ...: (..., ...),
}

This brings a few challenges:

• Matching potentially more complex language specs such as de_DE, or pt_PT / pt_BR to the respective entries (nothing would stop such dict from having fully specific entries, of course, but the specific-to-general fallback might need to be coded...).
• Guiding translators to both create/edit the gettext translation files and edit this dict.

Going crazy

A completely crazy but that might actually work idea is as follows:

• Have the default "960" and "1200" EN widths as translatable strings. The code would then "translate" and create the necessary ints at runtime with something like if width < int(_("960")): # icon is small.
• Then have each translation translate the "960" and "1200" strings to the appropriate values for the language!!! :) :) :)

Notes:

• I went looking for an int based gettext translation function/method, but found it to support text strings exclusively (which makes some sense, I guess).
• The numbers I shared above were obtained from quick experimentation on macOS. Full cross-platform testing should be used to fine tune them to a reasonably effective value that will work without an extra level of per-platform-ness configuration.

Parting thoughts

This is clearly a hack. However, if properly documented, it somehow feels kind of right: all the translation "info" is in the same file, edited at the same time, committed in a single "unit".

Please tell me this is not acceptable and that we should follow a "textbook" approach. :) :) :)

[ntoll]

OK... I like where this is going. However, one of the final "alpha" features I want to implement is for the user to override/define icon size on buttons. This feedback was given several times by teachers and speakers (Dave Beazley, no less) when they've been telling me how they use Mu as a tool of pedagogical presentation... they felt the attention should be on the code so, "please can we have a way to say less buttons".

Any thoughts on this?

Personally, we could introspect the width of the button widgets, sum them together, add a little bit for heuristic reasons and set the width of the whole editor to that.

[carlosperate]

If the main reason is to emphasise the code over the editor UI, maybe a focus mode also serves this purpose and might be easier for users to use? Enabling/disabling, rather than configure values in the settings, just a thought.

[tmontes]

@ntoll, @carlosperate,

Thanks for your input. You catch me on my way to a very-much-needed holiday week ahead, so I'll probably only get back to this in a week or two, but I wouldn't want to go without at least commenting back. :)

OK... I like where this is going. However, one of the final "alpha" features I want to implement is for the user to override/define icon size on buttons. This feedback was given several times by teachers and speakers (Dave Beazley, no less) when they've been telling me how they use Mu as a tool of pedagogical presentation... they felt the attention should be on the code so, "please can we have a way to say less buttons".

Any thoughts on this?

I had that specific use case in mind and was deferring additional capabilities to complementary PRs, mostly for two reasons:

• Smaller PRs are easier to review, adapt, and merge.
• I figured that the UI/UX to set button size preferences could need some thought and discussion.

What I was trying to "solve" was the single problem of improving the existing auto button sizing code, such that all buttons are visible all the time, growing/shrinking as the window width allows (of course, when the window is not wide enough, not all buttons will be visible, and that's ok).

The code to solve that is mostly in place, pending a decision around the idea of "how to specify" per-language window width / icon size thresholds:

• Somewhere in the code (cleaner/better design) or...
• ...somewhat hacked into the translations themselves (easier for translators, thus).

(I'll share a few thoughts on the "set button size preference" below.)

Personally, we could introspect the width of the button widgets, sum them together, add a little bit for heuristic reasons and set the width of the whole editor to that.

I'm not sure I understand this note: it seems to dictate a constraint source/destination that I haven't identified in this context. AFAIU, your words say "add up button widths and set the window width from there", while what I'm looking to improve is essentially the other way around, "determining button sizes from a given window width" -- in the sense that it is up to the users to size the window as they see fit, and that buttons should adjust accordingly.

Am I missing something? :)

Possible UI/UX for setting preferred button size

There are currently three auto selected toolbar button sizes: small, medium, and large. These are automatically set -- something this PR is trying to improve to be more consistent and UI language independent.

Question:

• Which choices should users have WRT to button sizing? Those three and "automatic"?
• What about the "focus mode" idea that @carlosperate commented on? Would that be a fifth "buttons not visible at all" option, or something else?
• What would the "default" / "out-of-the-box" choice be? I'm inclined towards "automatic" to keep the behaviour as is.

UI/UX options:

• Add one more tab to the "Mu Administration" window with UI related preferences: a drop down box would allow users to set their button size preference.
• Right-clicking the toolbar itself would bring up a popup menu with the available options (more advanced, non-discoverable).
• Both?
• Something else?

Entering "listen mode"... Thank you! :)