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).

[SpomJ]

I'm waiting on feedback whether my master merge in this one is fine or not, so that we may close out one of the PRs.

I have no idea either. I guess we should ask @messmerd ?

[SpomJ]

I did some pushes to #7586 in the meantime, idk what do we do with this branch... Do we just pull from #7586?

[messmerd]

@SpomJ Since you've been working on this feature (thank you by the way!), I think it's up to you which branch(es) you want to contribute to. I'm just happy to see progress on this, so I'm fine with either option.

[messmerd]

@lukas-w Your master merge appears similar to what I did as far as I can tell. I was mainly concerned with SubWindow::adjustTitleBar(), so I added a couple TODO comments there when I was resolving the conflicts.

[SpomJ]

I think I'd like to get rid of attach-on-show behavior we currently have, however that poses another question. How should we return the window back? Most WMs lack a dedicated attach button.

Setting up a keybind is the most elegant way I see, however as for now, LMMS lacks a dedicated shortcut setter and we'd need to clarify somewhere that it exists at all. I'd be happy to hear your opinions on this one.

---

Edit: I have a working commit for this, and even appears to fix the mentioned issues with controller rack (it seems calling attach() for the first time while widget is hidden causes resizing issues). I probably won't push it until we figure out what should call attach though, since nothing calls it then.

[SpomJ]

The controller rack behavior also seems really weird, and I don't know what's causing it. It loads fine, but then snaps the subwindow to what appears to be embed size for no apparent reason. My commit is apparently a workaround for this, but that shouldn't be happening in the first place.

[lukas-w]

I don't really like the backwards transition here, it feels quite counter-intuitive

Yeah I'm not very fond of this either, it was a poor choice but at the time felt like the easiest solution without introducing more complex changes. Some ideas that come to mind that may be better:

1. Re-attach on window close
2. Re-attach on keyboard shortcut, which could be displayed briefly as a popup hint when detaching
3. Have the detached window keep the custom window frame to keep access to the detach/attach button. Probably the most intuitive for most users using floating window managers, but more work to implement. May make it necessary to replicate some of QMdiSubWindow's features to e.g. that can't be overwritten in a subclass. This may have limited support on some Wayland compositors.
4. Be fancy and find a way to allow simply dragging a subwindow out of and into the main window to trigger a detach or attach respectively; similar to how browsers allow moving tabs to a new window by dragging the tab & dropping it outside of the window in an empty area. I like this most from a usability perspective, but dragging into the window again will not work with Wayland as far as I know.

I think 1. is the sanest choice here because it's very simple, would work on any desktop / window manager and while I don't know if I'd call it intuitive, users will probably discover it quickly which can't be said about the current solution at all. The downside being that users who actually want to get rid of the window altogether will have to click twice.

I did some pushes to #7586 in the meantime, idk what do we do with this branch... Do we just pull from #7586?

We can't just pull because #7586 is rebased on a newer master, so merging it back to feature/detach-window would duplicate all commits made there. Hence my aversion to unnecessary rebasing 😁 It makes collaboration harder. If I have your OK though, I'll cherry-pick the new commits made there so that work may continue targeting the original branch. 👍

[SpomJ]

1. Re-attach on window close

This would actually be really nice if it could be toggled in settings. If only we had actual settings...

3. Have the detached window keep the custom window frame to keep access to the detach/attach button. Probably the most intuitive for most users using floating window managers, but more work to implement. May make it necessary to replicate some of QMdiSubWindow's features to e.g. that can't be overwritten in a subclass. This may have limited support on some Wayland compositors.

This one is... interesting. Client-side decorations are a thing, and would probably work beautifully if implemented properly. I have two complaints against this, however. First, it would probably take a bit of unnecessary boilerplate, if Qt can make this happen at all. And second, I rely on tiling WMs and consider title bars ugly :]

4. Be fancy and find a way to allow simply dragging a subwindow out of and into the main window

at this point it would be easier to just get rid of QMdiSubWindow altogether and just detach all the windows. This messes up the usual 2d-scrolled landscape and makes windowing unnecessarily janky, especially if you have other windows floating alongside LMMS.

---

So out of all these the most pleasing to me (i'm biased btw) is a shortcut, although again adding shortcuts without a way to change them makes me sad. If I understood you correctly, you essentially want to make close button an attach one, which would be nice aside from the fact it would require patches for non-persistent things (like microtuner) where closing them makes more sense (and therefore makes the code just so slightly more obese).

[SpomJ]

If I have your OK though, I'll cherry-pick the new commits made there so that work may continue targeting the original branch.

Do as you please (and on the way you can squash two commits where I screwed up size constraints on itw and almost immediately patched it afterwards :)

I'm happy to contribute to whatever branch I have write access to.

[SpomJ]

Regarding remaining issues.

I'll reiterate my thoughts on resizing issues. For whatever reason SubWindow (actually, widget minimalSizeHint) does not respect the widget's size constraints, and only snaps to requested size once moved/resized by user. Calling resize() on SubWindow does not check for these constraints. For this reasons, some constraints in code are set for subWin instead, giving tolerable results; however this does not impact detached windows in any way since only the embed (without the SubWindow) gets detached.

This is what caused "Add" on controller rack not to be visible, resulting in me using a bad workaround, and this is what causes constraint issues specifically on SlicerT which I tried solving for several days at this point and intend to give up soon. I could use the same workaround, but this doesn't get us anywhere in the long run, since at the end of the day it is still very much a workaround.

I have no clue on how to fix this, and apparently no one in #dev-support either cares or knows either.

---

Other than that, basically no issues remain. I can't test the icons thing, so I'm probably the last person to fix it. The attachment thing seems to be a design decision, and can be reverted with relative ease in favor of anything we discussed. Window translation is annoying, but can probably be fixed just by throwing the window to center in attach() which shouldn't be that hard. (solved)

---

So ignoring the first part, this is pretty much one step away from being mergeable.

[lukas-w]

And second, I rely on tiling WMs and consider title bars ugly

Same. I don't mind a slim bar though if it provides important application features. Firefox draws its own title bar and it never bothered me because it actually has a purpose by integrating the tab bar. If it didn't it wouldn't be possible to attach a single tab window back into another one so that's a win to me.

at this point it would be easier to just get rid of QMdiSubWindow altogether and just detach all the windows

This would be awesome for us two tiling window manager users out there but a GIMP-2.0-trauma-triggering constant-window-misplacing nightmare for everyone else. 👻

[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.