Mixer changes width of inspector when undocked.

• May 27, 2019 - 19:10
Reported version
3.x-dev
Priority
P1 - High
Type
Graphical (UI)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

Viewing the mixer causes the inspector to increase its width even though it is undocked. The inspector only needs to change its width if the mixer is being docked. The default behaviour should be that Musescore retains the inspector width except when docking the mixer.

See video of current behavior:

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.7011, revision: 8b1a7dc

mixer_changes_inspector_width.gif


Comments

In reply to by Marc Sabatella

Interesting. I've got a fair inkling as to why this might be - a side effect of addressing the mixer docking problems and related other issues. The mixer is, I believe, unique in that it's the only dockable widget in MuseScore that defaults to opening in the un-docked state. There is a workaround in that you can just make the inspector narrower again after showing the mixer, so this doesn't entirely undo the inspector narrowing work Marc mentions.. But clearly undesirable. And if your workflow involves regularly hiding and un-hiding an un-docked mixer, this is going to be a real pain. I'll investigate further and see if the code can be smartened up to cope with this case.

Setting the "Fix version" to 3.1 seems misleading to me as this regression was introduced with the 3.1 release candidate. Shouldn't "Fix version: 3.1" mean the issue was not fixed in previous releases (for example 3.0.5) and was fixed in 3.1?

In reply to by Jojo-Schmitz

The QT behaviour is, I'm reasonably confident, to do with the minimum width of the panel being opened. When the mixer is showing detailed view, its minimum width is pretty wide - when details are hidden its minimum width is smaller than than the minimum of the inspector.

If detail view is hidden and you show and hide the mixer the impact on the dock widget area still occurs, but usually it won't be noticed because the dock area is likely to be wide enough anyway.

There maybe a workaround - or just more subtle code - where the mixer detail view can be closed when the mixer is added to the dock and then re-opened when or just before it is shown. Reverting PR 5011 will resolve the issue flagged here. However, it's also the case that the mixer display issues were, arguably, worse before in that people were reporting losing access to the mixer altogether and also crashes. Either way, I'll look at generating a new PR in the next wee while to handle the mixer case better. Might not be until the end of the week though.

See:
* https://musescore.org/en/node/283258
* https://musescore.org/en/node/281742

To me, if the Qt issue isn't resolved, a reasonable option is to not have the mixer dockable at all - I'm not convinced this adds any value. Or at least have it default to undocked as was formerly the case, if that works around the problem.

In reply to by Marc Sabatella

I like having the mixer dockable, easily accessible. The volume levels of instruments are a little different in the online player than those set in the application. To get the levels I want online, I have to play with the levels while updating the score until it matches with the application.

I think that QT bug report is a red herrings at least for this case. Tweaking PR5011 code looks to sort this out. I will test a bit more to and then amend PR / provide new PR.

Fix version
3.2.0