Mixer changes width of inspector when undocked.

A regression and I think a significant one considering the work that went into making it possible to make the Inspector narrower.

Relates to #289565: [Epic] 3.1-RC Regressions that must be fixed

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.

Doesn't it default to docked, though? It does for me, at least in 3.1 I just did a factory reset to be sure.

Fixed by reverting PR 5011, see this comment for more details.

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?

better than Fix version: - None -
And Reported version: 3.x-dev should give that hint, if needed, along with the Regression flag

oops

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.

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.

Automatically closed -- issue fixed for 2 weeks with no activity.