Feature: Detach window

[lukas-w]

Allows detaching a window from LMMS's main window, making things like working on multiple screens easier.

Closes #1259

Quick demonstration:

Edit: This uses some Qt5-only features, so it's best to wait with merging this until we've switched (#2611).

[BaraMGB]

Wow! That's really awesome!

[karmux]

Very useful functionality especially when using multi-monitor setup! 👍

I played a little bit with it and found some bugs:

1. When detached instruments are maximized then all instruments stay maximized inside LMMS until LMMS runs. I think there shouldn't be maximize button and functionality for instrument windows at all.
2. Mixer, project notes and controller rack can't be closed once detached. Clicking on X-button does nothing.
3. Trying to close instrument when detached crashes LMMS every time.
4. Detaching any window and then clicking minimize freezes this window inside LMMS main window and the subwindow border icons/labels don't look correct. Expected functionality is to minimize detached window same way like main window.
5. Detaching any window and then clicking maximize maximizes it inside LMMS main window and scrolling main window too much to the right. Expected functionality is to maximize detached window same way like main window.

LMMS 1.2.0-rc2.153
(Linux x86_64, Qt 5.7.1, GCC 6.3.0 20170406)

[lukas-w]

@karmux Thanks for testing! I'll have a look at the issues you pointed out as soon as I find the time. I already noticed number 2 (X-button doesn't work), but couldn't find the cause.

[ivhacks]

This is super useful!!

I can't seem to make a windows build of it though. The build seems to go without a hitch, but when I open the app, it doesn't have the detach button. This might be my own error, but maybe someone else should look into it.

I can confirm all the issues that @karmux pointed out. Also, getting the detached window back into lmms is a little unwieldy. I basically need to re-open the window (for exmaple, clicking the FX-Mixer button to re-attach the FX-Mixer). Not exactly a bug, but it would be useful if the minimize button reattached the window, or if there was another button entirely.

Good job, looking forward to be able to use this for major producing :)

[NickAcPT]

Sorry for the bump.
@Jousboxx I agree with you when you gave the idea to make the minimize button reattach the window into LMMS.
But, if they were going to add a button inside the window to attach it back, they would need to adjust the window's content to account for the button.
Also, if you were talking about adding a button to the title bar, that would be a bit complicated and hard to maintain.

PS: Sorry to bother...

[ivhacks]

@NickAcPT Yeah, my idea is that since the minimize button reattaches, they wouldn't have to add another button. The minimize button on the main LMMS window should probably shrink all child windows so there is a way to minimize them.

[PhysSong]

This uses some Qt5-only features, so it's best to wait with merging this until we've switched

Now we've, so I think we can continue working on this.

When detached instruments are maximized then all instruments stay maximized inside LMMS until LMMS runs. I think there shouldn't be maximize button and functionality for instrument windows at all.

It's already fixed.

Mixer, project notes and controller rack can't be closed once detached. Clicking on X-button does nothing.

Trying to close instrument when detached crashes LMMS every time.

vstSubWin, ControllerDialog, EffectControlDialog, FxMixerView, SongEditor(this is fine because SongEditorWindow doesn't), ControllerRackView, ProjectNotes and IntrumentTrackWindow class overrides closeEvent and ignores close event. See #1495 (comment) for why we have such workarounds.

Detaching any window and then clicking minimize freezes this window inside LMMS main window and the subwindow border icons/labels don't look correct. Expected functionality is to minimize detached window same way like main window.

Detaching any window and then clicking maximize maximizes it inside LMMS main window and scrolling main window too much to the right. Expected functionality is to maximize detached window same way like main window.

I guess the event is propagated to SubWindow in some way. Installing an event filter which blocks propagation seems to fix it.

[PhysSong]

Found some more issues:

• Window size is not preserved when using some window manager on X11(compiz on Ubuntu 18.04, unity session in my case). There's a known issue with frameGeometry on X11 so I'm not sure if we can work around this when attaching. It's from the difference between widget's size and subwindow's size.
• When switching instrument, detached windows get attached automatically.

[PhysSong]

if the minimize button reattached the window, or if there was another button entirely.

If the minimize button is used for attaching, wouldn't it be confusing? Also, I can't find platform-independent way to add such a button to the title bar unless we create a custom window class which would be quite difficult. There's an easier workaround, wrapping window content and window controls in a layout. It might be a little bit ugly, but it's easy.

@lukas-w may I continue this work?

[lukas-w]

@lukas-w may I continue this work?

Go for it. 👍

[PhysSong]

Fixed almost all bugs reported by @karmux. As a side effects, minimize button doesn't re-attach windows anymore. I can restore the behavior, but I think that might be confusing.
Bugs in #3532 (comment) still needs to be fixed.

[karmux]

@PhysSong thank you! During a quick test I couldn't reproduce any of my previously reported bugs.
While testing I discovered now that I can't close sample track instrument in detached mode. Maybe happens because I have #3866 merged.

[PhysSong]

Maybe happens because I have #3866 merged.

I think that's correct. IIRC I copied some code from instrument track and it had some issue(fixed in this PR).
When/If that one is merged, I will add a fix.

[lukas-w]

As a side effects, minimize button doesn't re-attach windows anymore.

It never did. This was just suggested by @Jousboxx in #3532 (comment).

[pwepwe973]

hello,
how to enable this option please?
thank you

[PhysSong]

@pwepwe973 This feature is in development and not a part of released versions. Sorry.

[pwepwe973]

thank you

@pwepwe973 This feature is in development and not a part of released versions. Sorry.

thank you for your message

[winniehell]

@PhysSong Can you please summarize the current state of this? Is it ready to be merged?

I'm willing to help get this finished if possible.

[PhysSong]

@PhysSong Can you please summarize the current state of this?

I unintentionally abandoned this one, but I can restart working on this.

Is it ready to be merged?

Not yet, mainly due to #3532 (comment).

[lukas-w]

@SpomJ I rebased your commits on top of feature/detach-window while squashing b477e6a and 8fa469d.

[SpomJ]

can i haz write access to this

[SpomJ]

I submitted a PR (#7592) to this, fixing wayland misbehavior.

[SpomJ]

I fixed all the bugs I know of and can test.

It's probably best to leave attachment behavior as it is, at least for now. We could probably hook attachment to minimize button instead, if there even is a call for that. I'd mainly go for shortcuts, but there's ongoing work on them, so it's probably best not to touch it for now.

I can't check anything about window icons, since y'know, wayland.

From further testing the best I can do about window constraints is set up a helper function which syncs them since setting either of these is not sufficient and there doesn't seem to be a way to dynamically infer one from another.

Is there anything that prevents this from exiting the draft stage?

[messmerd]

@SpomJ The taskbar icon bug isn't occurring for me anymore, at least when I built this branch locally with Qt 5.15.2. Maybe it was a Qt bug that got fixed upstream, or your changes fixed it somehow.

[messmerd]

The only bug I've found so far is that detached windows some detached windows can be resized past the minimum size. Other than that, everything seems to be working fine. I'll continue testing later today.

[SpomJ]

What are those windows? Only thing I know of still doing this is SlicerT and it seems to be reworked anyways, so I think tweaking it now would do more bad than good.

[messmerd]

SlicerT, Microtuner config, and the LADSPA plugin browser.

And Tap Tempo is resizable when detached but it shouldn't be.

[messmerd]

Found some more windows with resizing issues:
VST effect controls window, VST parameter windows (this also is missing its window's close button and the "Close" push button inside the window doesn't work), LADSPA effect windows, VST GUI windows

[SpomJ]

Disregard all my previous whines about SubWindows being broken. Turns out all I needed was layout SizeConstraint on SubWindow. I submitted a pr for this (#7596).

[SpomJ]

I should have fixed SlicerT, Microtuner, LadspaBrowser and Tap Tempo.

Regardng VSTs - Rack appears to wannabe-constrained (and thus, not intended to maximize) which is weird, considering its max size is strictly below its scroll area width (same applies to mixer btw). I also lack any embed protocols to test how VST windows behave.

Not sure what you mean by {VST,LADSPA} effect windows??

[SpomJ]

I also just discovered that setting fixed width does not prevent maximizing. Oh well, what a great thing Qt is.

[messmerd]

I tested the Linux AppImage that was automatically built for this PR, and there were some issues. The detach button didn't display correctly and the taskbar icon bug was back. However, when I built it locally, these issues were gone. I'm using Qt 5.15.2 locally, while the CI uses Qt 5.12.8, so they were likely upstream Qt bugs that got fixed.

#7316 updates our Qt version on Linux to Qt 5.15.2, so it would probably fix the CI issues here. I've just been waiting on people to review that PR.

[SpomJ]

@messmerd Since mixer can't be resized vertically anymore, shouldn't we disable maximizing? Is it even a good idea to disable vertical resizing?

[Rossmaxx]

Didn't we add resize ability for mixer recently? Why you saying it ain't resizeable?

[SpomJ]

It was added back in bf922af#diff-ae4b38c15f268a0cd930edea9a6481663edf21a1ff206291784fd55b8513904eR182 for some reason. This was written long before I joined the discussion so I didn't really question it lol

So should we revert that line?

[messmerd]

I haven't been following the recent work on the Mixer. If the Mixer in this PR deviates from the resize behavior on master, it should probably be reverted.

[SpomJ]

Also what's the desired behavior for VeSTige controller window? rn it's very janky, doesn't have a title nor a maximize button and its maximum width is less than embedded area width.

Should I unfix the width so that it can be maximized and resized? (Here it could also be beneficial to tamper with scrollarea to snap the controls into the empty space, but this is really out of scope now)
or should I just set the flag to stop maximizing so that the behavior persists

[SpomJ]

#7688 fixes everything remaining I know of.

If no new issues are found, after its merge this pr will be actually ready this time.