MuseScore
MuseScore copied to clipboard
musescore
Home/Score/Publish tab width should be determined by text's width when bold
Issue type
UI bug (incorrect info or interface appearance)
Bug description
In the Home/Score/Publish tabs, text is regular weight when the tab is not in its active state and bold when active (or in the case of Score, bold when a score is open).
Because of this, the width of each individual tab changes when selected/deselected and it causes a slight horizontal shift.
We should set the width of the text container based on its width when the text is bold and always center the text, so that when the text is regular weight, the width of the tab does not change.
- Make sure this works with different languages. The width should not be determined just by the English tab labels.
Steps to reproduce
Click between the Home/Score tabs
Screenshots/Screen recordings
https://github.com/musescore/MuseScore/assets/20806406/fd581299-6c8e-4509-9860-0dc717964d8a
MuseScore Version
4.2
Regression
No.
Operating system
macOS 14.1.1
Additional context
No response
@cbjeukendrup @avvvvve Let me fix this issue, not sure whether #11335 is completed or not. If it does not need any additional work, I will work on this.
That would be great @daijingz! I just added one note to make sure that this works with any language. Thanks!
@daijingz I was thinking it would be a good idea to use FontMetrics for this issue: https://doc.qt.io/qt-6.2/qml-qtquick-fontmetrics.html
@cbjeukendrup I forgot this section's name, which tab bar is it? The first step is, I am directly using the keywords "home", "score", and "publish" to search in the program bases, but I found a lot of files have these strings. But there is no better source to discover the corresponding code positions. Do we have any keys for these three tabs?
@avvvvve From observation, it is clear that this bug does not occur on Windows (since my machine is Windows, and I did not see such errors during testing). I guess the problem takes place on the QML file specializing in the MacOS system.
@daijingz See src/appshell/qml/MainToolBar.qml (this one is indeed a bit difficult to find if you don't know it yet)
In principle the bug should occur on Windows too, but it can be more or less apparent depending on the font and language (e.g. for some fonts, the difference in width between the regular and bold variant is bigger than for others).
Would it be alright if I was assigned to this issue? I was looking through the qml part of the code and I believe I have found a fix using the TextMetrics you mentioned within the definition of the PageTabButton, as making changes purely on the aforementioned file caused a problem with the buttons' position on the page
Unless @daijingz has a PR ready (@daijingz please let us know), feel free to create a PR!
Would it be alright if I was assigned to this issue? I was looking through the qml part of the code and I believe I have found a fix using the TextMetrics you mentioned within the definition of the PageTabButton, as making changes purely on the aforementioned file caused a problem with the buttons' position on the page
Giving Solutions so quickly! I am still working on it, seems like it is later than @SirKuzalot. Whatever his result is, I am going to submit my PRs.
@cbjeukendrup I see he may have different solutions than me (because he changed some files seems irrelevant), but whatever it is, I am going to submit my solutions too.
Giving Solutions so quickly!
@daijingz I don't understand what you mean. Do you mean that you will open a PR very soon (like, today), or do you mean that @SirKuzalot was very quick and therefore he can open a PR instead?
I am terribly sorry for the mild commit spam, I was having trouble getting the description correct. The following will be final and I'll start working on creating the PR
My attempt: ONLY AT src/appshell/qml/MainToolBar.qml
Here is the update:
Here I define a new font metric, to receive updated title width and resize the metrics. It is error-free on syntax, but I did not submit my PR because I have not tested this. My machine has some implementation problems. @cbjeukendrup Very sorry to say.
This is my error: (The same error before and after my modifications)
(Just ignore those unrecognizable words because I have already switched the language to English, but there are still some other languages' words.) I rebuilt several times, sometimes 5 errors, sometimes 9 errors, and sometimes even 17 errors.
I did not change anything, I just updated the MuseScore day by day, and after updates, these errors occur. Before rebuilding and re-opening options made sense, so I did not spend so much time on this. But this time, the situation is strange.
@SirKuzalot If you can please try my code, I know your solutions may be well working for this issue, but changing general files may result in other code section modifications.
@cbjeukendrup code is ready but has not been tested, please decide for me: whether or not I should submit it now.
Let me try to re-run it after tomorrow's updates from others.
@daijingz Though it is true that changing the general file could be problematic, I chose it as a solution for this problem, not only because purely changing the size of the buttons in the main tool bar seemed to offshift the buttons, but also because the problem presented would be common to any buttons that made use of the component I altered, as the buttons themselves were set to change size
@daijingz It's strange that the compilation fails, but I can't really help with that because I can't read the Chinese error messages.
https://github.com/musescore/MuseScore/pull/22132 has not yet been merged, so therefore it isn't closed yet, but yes, it's pretty much completed.
@cbjeukendrup I do not know why my answer has some problems here, because the program just terminates without error messages. I did not find some syntax errors, but do I change in the correct place (I mean my modification positions)? Let me choose a new issue and submit my PR ASAP.
@cbjeukendrup meet something wrong, fixing it. During compilation there is an error: D:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.36.32532\include\xmemory:2096: error: C2259: "muse::SystemInfoMock": cannot instantiate abstract class D:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.36.32532\include\xmemory(2096): error C2259: "muse::SystemInfoMock": cannot instantiate abstract class D:\MuscScore\MuseScore\src\framework\global/tests/mocks/systeminfomock.h(30): note: see declaration of "muse::SystemInfoMock" D:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.36.32532\include\xmemory(2096): note: because of the following members: D:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.36.32532\include\xmemory(2096): note: "muse::Version muse::ISystemInfo::productVersion(void) const": is abstract D:\MuscScore\MuseScore\src\framework\global/isysteminfo.h(52): note: see declaration of "muse::ISystemInfo::productVersion" D:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.36.32532\include\memory(2105): note: see reference to class template instantiation "std::_Wrap<_Ty>" being compiled
I tried to remove my modifications, however, this compilation error still exists. I just tried to use different versions (by updating it continuously, however, this still exists). Can you show me where is the problem?
The error code is C2259 in Qt creator, and I believe this is not my modification's problem.
@daijingz It seems something was wrong; see #22610. But the reason that this problem didn't happen to us is probably that you hadn't re-run the CMake configure step after rebasing. Anyway, let's please have this discussion on Discord in #development, because it isn't related to this issue.
@avvvvve Now that there is a working solution in #22055, I realised that this has the implication that the spacing becomes uneven. Currently, the padding between the boundary of the button and the text is some fixed amount of pixels. Making the button as wide as it would be when the text is bold, means necessarily that some extra padding will be added when the text is not bold: half of the difference in width between the bold and non-bold text is added to each side. Since this difference naturally varies per word, that may produce uneven results. Here is Dutch for example:
This seems not a technical limitation, but a geometrical limitation.
So, it's a trade-off between this unevenness and the changing width when changing tabs. What do you think?
@cbjeukendrup I feel if this is a question about choosing one option from binary choices: the mentioned unevenness and the changing width when changing tabs, then changing width is a better choice. Because if following our original design (not only my attempts but also @SirKuzalot attempts), the button length is a fixed number, meaning that it can only capture the text no longer than its length.
Although all texts are short words, I wonder if some available languages translate them into long, long strings, the fixed length may not display the complete text.
The width is not fixed; it is calculated based on the text. So no text clipping will occur. Anyway, my question about which option to choose was primarily intended for @avvvvve.
@cbjeukendrup Short answer: I'd say the slight difference in spacing that results from this change will mostly be trivial—I'm not sure I would've noticed it in your screenshot if it hadn't been pointed out. So let's move forward with this solution!
Long(er) answer: The difference is most obvious in the space to the left of "Ontwikkelaarstools" since that's the longest string and therefore has more extra padding, but most users won't see that option anyway since it's only in the development builds. I am taking a bit of a leap in assuming that the other three tabs titles will be shorter than that in most languages, and even if they are super long, ideally we (i.e. translators) should find shorter labels since these tabs shouldn't take up a ton of horizontal space anyway.
For what it's worth, Portuguese (in which I have the program set) has one of the longest strings in that part (I forget the exact wording but it's at least 20 characters) and the padding is not all that significant
Right, and that's still the DevTools tab which won't be seen by non-dev users (not to say devs don't deserve a beautiful app too - but it's still better than the tabs jumping, IMO 😄)
Oh yes, sorry I misunderstand the mentioned problem. The padding is just a few pixels and it won't take much space (minimized effects).