Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Detach window #3532

Open
wants to merge 20 commits into
base: master
Choose a base branch
from
Open

Feature: Detach window #3532

wants to merge 20 commits into from

Conversation

lukas-w
Copy link
Member

@lukas-w lukas-w commented May 5, 2017

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

Closes #1259

Quick demonstration:
lmms-window-detach

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

@BaraMGB
Copy link
Contributor

BaraMGB commented May 5, 2017

Wow! That's really awesome!

@karmux
Copy link
Contributor

karmux commented May 6, 2017

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
Copy link
Member Author

lukas-w commented May 6, 2017

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

@Umcaruje Umcaruje added this to the 1.3.0 milestone May 7, 2017
@ivhacks
Copy link
Contributor

ivhacks commented May 7, 2017

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
Copy link

NickAcPT commented Oct 9, 2017

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
Copy link
Contributor

ivhacks commented Oct 9, 2017

@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 PhysSong mentioned this pull request Mar 12, 2018
@PhysSong
Copy link
Member

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
Copy link
Member

PhysSong commented May 23, 2018

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
Copy link
Member

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
Copy link
Member Author

lukas-w commented May 24, 2018

@lukas-w may I continue this work?

Go for it. 👍

@PhysSong
Copy link
Member

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
Copy link
Contributor

karmux commented Jun 17, 2018

@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
Copy link
Member

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
Copy link
Member Author

lukas-w commented Jun 17, 2018

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
Copy link

hello,
how to enable this option please?
thank you

@PhysSong
Copy link
Member

PhysSong commented Oct 9, 2018

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

@pwepwe973
Copy link

thank you

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

thank you for your message

@winniehell
Copy link
Contributor

@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
Copy link
Member

PhysSong commented Nov 7, 2019

@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
Copy link
Contributor

SpomJ commented Nov 18, 2024

These are the known bugs that still remain:

  • Detached microtuner config window doesn't close when "X" is clicked

  • When switching instruments, detached windows get attached automatically

  • The LMMS taskbar icon changes to the icon for the most recently detached window

  • Some detached windows look really bad when maximized, so they should be prevented from maximizing if possible

  • The "Add" button in the Controller Rack is not visible at first when attached

Meanwhile I think I managed to fix some of these.

At this point known ones are:

  • When switching instruments, detached windows get attached automatically (design choice)
  • The LMMS taskbar icon changes to the icon for the most recently detached window (Confirmed to be somehow fixed)
  • Some detached windows look really bad when maximized, so they should be prevented from maximizing if possible (maximizing respects window constraints which are set)
  • Controller Rack "Add" button invisible (fixed, was caused by wrong minimal size, a sort-of-regression caused by 4b3bf9f)
  • Detached microtuner config being unable to close (fixed, missed QWidget into DetachableWidget conversion)

+ Newly discovered:

  • Knob hints appear on main window instead of being pop-up (fixed, SimpleTextFloat transitioned to QToolTip)
  • Windows get translated to 0-0 when attached (Issue on Wayland side, but a fix would be nice in the meantime) (fixed the best we can. Unless wayland decides to grand us power back this is what we get.)

@SpomJ
Copy link
Contributor

SpomJ commented Nov 18, 2024

Quick demonstration:
lmms-window-detach

I don't really like the backwards transition here, it feels quite counter-intuitive and this is what I believe to be the cause of detached windows being attached on instrument switch.

@SpomJ
Copy link
Contributor

SpomJ commented Nov 18, 2024

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
Copy link
Contributor

SpomJ commented Nov 20, 2024

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

@messmerd
Copy link
Member

@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
Copy link
Member

@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
Copy link
Contributor

SpomJ commented Nov 20, 2024

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
Copy link
Contributor

SpomJ commented Nov 20, 2024

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
Copy link
Member Author

lukas-w commented Nov 20, 2024

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
Copy link
Contributor

SpomJ commented Nov 21, 2024

  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
Copy link
Contributor

SpomJ commented Nov 21, 2024

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
Copy link
Contributor

SpomJ commented Nov 21, 2024

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
Copy link
Member Author

lukas-w commented Nov 21, 2024

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
Copy link
Member Author

lukas-w commented Nov 21, 2024

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

@SpomJ
Copy link
Contributor

SpomJ commented Nov 21, 2024

can i haz write access to this

@SpomJ
Copy link
Contributor

SpomJ commented Nov 21, 2024

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

@SpomJ
Copy link
Contributor

SpomJ commented Nov 21, 2024

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 messmerd marked this pull request as ready for review November 21, 2024 19:26
@messmerd
Copy link
Member

@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
Copy link
Member

messmerd commented Nov 21, 2024

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
Copy link
Contributor

SpomJ commented Nov 21, 2024

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
Copy link
Member

SlicerT, Microtuner config, and the LADSPA plugin browser.

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

@messmerd
Copy link
Member

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
Copy link
Contributor

SpomJ commented Nov 21, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multiple Monitors