For horizontal panels, show tab bar instead of title bar #22050
Conversation
|
Looks good! |
|
Nice!! Something odd going on with the drop shadow when undocked :) Think it's not feathered |
|
And for some reason, opening the Mixer the 2nd time, crashes the app. No other MS4's were open. Screen.Recording.2024-03-26.at.10.48.21.720.mov |
cbjeukendrup
force-pushed
the
mixer_toolbar
branch
from
a80b234 to
b02d076
Compare
|
@jessjwilliamson Drop shadow will be back in #22046! (Was a Qt 6 regression.) I can reproduce a crash sometimes, but not reliably. I'm having difficulties finding out what's causing it. @Eism Could you perhaps take a look? I fixed the navigation order of the panels, and temporarily hid the "Customise Mixer" button until it's fully implemented. |
|
@cbjeukendrup @jessjwilliamson I fixed the crash, please review |
cbjeukendrup
force-pushed
the
mixer_toolbar
branch
from
7d8c9e6 to
f40721a
Compare
|
@Eism The crash fix works indeed, and I rebased! But just now I found another regression: when opening the Mixer while another panel is already open, it does not become the active tab. So I'll need to fix that. Not sure if that will be before 4.4 (probably better to delay this, as it might be a bit too risky at this stage) |
Add new components to Muse/Dock/qmldir Turns out to be necessary after rebase
KDDockWidgets requires using two MouseAreas: one for dragging the title bar (which will drag the whole floating window when it's undocked) and one for dragging individual tabs (this will drag the tabs out of the floating window, which gives a strange effect when there is only one tab in the floating window. The design specifies that we want tabs instead of a title bar for horizontal panels even when there is only one tab. In this case, we need to make the tabs visible, but make their MouseArea disabled, and instead use the title bar MouseArea.
cbjeukendrup
force-pushed
the
mixer_toolbar
branch
from
f40721a to
7746121
Compare
Old situation: you tell the docking system a navigation panel for each dock panel, and the docking system will mess with the order of this panel. Problems: if a dock panel contains multiple navigation panels, you need to chain those other panels to the first one. And if the first panel is not really available, as in the case of the mixer toolbar, you can't tell the docking system about it. New situation: you tell the docking system about the navigation section directly, instead of the navigation panel. The docking system will give you a `contentNavigationPanelOrderStart` property back, which you can use to correctly set the order of all navigation panels in your dock panel.
reset toolbarComponent when destroying panel
It doesn't look like this bug has had any noticeable consequences though.
cbjeukendrup
force-pushed
the
mixer_toolbar
branch
from
7746121 to
a5024fd
Compare
|
@mathesoncalum @Eism Rebased! |
|
Tested on MacOS 14, Windows 11, Ubuntu 22.04.3. Approved |
And add a proof-of-concept mixer toolbar button (not functional yet).
Somewhat related to #22016 and #11335
Or actually the most to #16722
Resolves #11335