Add menu shortcut texts for non-darwin OS

[ErikKalkoken]

Description:

The current implementation renders menu shortcuts exclusively in macOS style, which might be confusing for users on Windows and Linux (see also #5108).

This PR adds a new generic style for rending menu shortcut texts on non-Darwin OS, while keeping the existing macOS style for Darwin OS. The generic style is mostly spelling out the names of keys instead of using symbols and should be much easier to understand for Windows and Linux users. The style is based on the VS Code shortcut documentation for Windows and Linux.

Additional changes

• Refactored existing code
• Added unit tests for function that generates shortcut texts

Example screenshot

Fixes #5108

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

Where applicable:

N/A

[coveralls]

coverage: 59.991% (+0.01%) from 59.98%
when pulling 64fda1b on ErikKalkoken:feature-5108
into b529a32 on fyne-io:develop.

[Jacalz]

Nice idea. Thanks for this. I've left some of my own ideas on the code but I think it would be wise to have @toaster have a look as well.

[Jacalz]

This comment does not add any value over the variable name. Either remove it or write something more helpful.

[ErikKalkoken]

Thank you for taking the time to review my PR.

I will rework the comments.

[andydotxyz]

Yes a runtime check might seem simpler (not sure how using runtime checks is easier to unit test TBH).
But for efficiency the build flags are preferable because there is less code to compile and the compiler can eliminate or inline the static const/var declarations etc.
I don't think that Jacob was asking for the "2) hybrid" I would have thought that using A) for all of them matches the current code style most effectively.

P.S. do check that the font must be different before coding that in - I think that if you choose symbol it would fall back to the normal font if the item is not in fact a symbol.

[Jacalz]

I entirely agree that A matches what we already have the best. It is good to be consistent with that and also not compiling in unnecessary code can be a win (sometimes also for readability).

To be fair, I did actually suggest B initially because that better described what I meant with "moving out the four if-statements" and because it was a smaller change from the existing code in the PR. However, I do agree that A is more consistent with what we already have and likely is the better path forward.

[ErikKalkoken]

tyvm both for the clarification and your patience. I will rework the solution to exclusively use build flags.

@andydotxyz

Yes a runtime check might seem simpler (not sure how using runtime checks is easier to unit test TBH).

With runtime checks you can make the current OS a parameter of the textsForShortcuts() function and then test all OS cases with unit tests (see also my initial commit for an example). This works here, because the "platform specific" code is just some different texts and formatting and runs on all platforms. But I fully understand your point about consistency; this was just to answer your question.

[andydotxyz]

Thanks, A helpful answer. It is indeed true that with the build flags the unit tests cannot cover all systems on one run, but CI provides the checks for those systems - so overall we get the optimised path but get the test runs too.
You'll find that on this path some tests /have/ to run on the target system (such as visual confirmation that symbols render in menus) - so the infrastructure is already set up that way.

[ErikKalkoken]

Here is my new attempt ready for review.

[Jacalz]

Thanks. I had a very quick look through the code on my phone and it looked great. Will follow up with a proper review later in the week when I have more time :)

[Jacalz]

Thanks. Sorry for the late review; I've been quite busy recently. This looks great. Just one minor comment about modifying the window size of one of the test images :)

[Jacalz]

Perfect. Thanks for working on this 👍

[ErikKalkoken]

Perfect. Thanks for working on this 👍

Thank you again for your review and patience with my PR. This is my first feature submission for Fyne and I am still learning how everything works.

The tests are now passing on my branch. Seams to be those flaky tests again acting up.

[Jacalz]

Thank you again for your review and patience with my PR. This is my first feature submission for Fyne and I am still learning how everything works.

No worries. Glad we all got to the same page in the end. Congratulations on your first PR then :)

The tests are now passing on my branch. Seams to be those flaky tests again acting up.

Yeah, sorry about that. Seems like the coverage upload is a bit flakey. Strange. Either way, kicking the tests made it all pass now so I'll merge 👍