-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Maximize button for resizable instruments #7514
base: master
Are you sure you want to change the base?
Maximize button for resizable instruments #7514
Conversation
Show the maximize button for resizable instruments. Most other changes have the character of refactorings and code reorganizations. Remove the negation in the if condition for resizable instruments to make the code better readable. Only manipulate the system menu if the instrument is not resizable. Add a TODO to the special code that sets a size.
Ok, this one is weird. I have added the following code snippet to
As you can see setting the style sheet is commented out and can be commented back in. Here's how the maximized window looks without a style sheet being set: The title bar of the window can still be seen for some reason. Here's the same situation but with the style sheet being set for the new window/widget: Now there is no title bar and it looks like expected. I guess the instrument window is in some strange in between state. Does anybody have an idea what causes this behavior? |
This seems to be caused by LMMS' own
|
In `SubWindow::paintEvent` don't paint anything if the sub window is maximized . Otherwise some gradients are visible behind the maximized child content. In `SubWindow::adjustTitleBar` hide the title label and the buttons if the sub window is maximized. Always show the title and close button if not maximized. This is needed to reset the state correctly after maximization.
Add the helper method `SubWindow::addTitleButton` to reduce code repetition in the constructor.
Disable the minimize button by taking the current flags and removing the minimize button hint from them instead of giving a list which might become incomplete in the future. So only do what we want to do.
Remove a dependency on the `MdiArea` when checking if the sub window is the active one. Query its own window state to find out if it is active.
Fix a typo and add a newline to the end of the file.
@michaelgregorius, I have plans to revert a good chunk of #7453, which would affect this PR. I don't think we should keep moving forward with making SlicerT bigger/resizable for now until we properly rework the instrument window to support larger sizes the right way. Effect racks and (at the very least) Lv2 layouts do not render properly and the envelope tab is massively distorted. We will always have another chance at making the instrument windows bigger, it's not like I am throwing that idea out completely. I just don't think its worth progressing further with this knowing the massive regressions we still have to deal with (and I do not like how resizability/bigger sizes for instruments was implemented). |
@sakertooth, this pull request can be reviewed and merged nevertheless. The changes in So, I'd appreciate a review. |
This PR will conflict with #7524 . I would like to ask for time to consolidate the differences and commonalities to avoid merge conflicts and unncessary commits. |
|
||
if (m_instrumentView->isResizable()) | ||
{ | ||
// TODO As of writing SlicerT is the only resizable instrument. Is this code specific to SlicerT? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, with #7201 , there will be a lot more resizable instruments. I will try to address this to make it work with Lv2.
As my PR from #7524 does not fully work after the SlicerT update and conflict with your PR, I will try to use your PR for Lv2 and then see what I need to change. Wish me luck 😄 @michaelgregorius As for your PR, isn't this two separate things in one PR? Do you think it would make sense to split this PR into "add maximize button" and "fix resizing behavior"? |
Good luck then! 😅
Yes, it can definitively be separated as you have described. Therefore I have now separated the sub window fixes into pull request #7530. Do you want to review it? |
Yes, thanks, I added myself to the reviewer list. I'm already in the middle of testing, most things look good. |
Show the maximize button for resizable instruments.
Most other changes have the character of refactorings and code reorganizations.
Remove the negation in the if condition for resizable instruments to make the code better readable.
Only manipulate the system menu if the instrument is not resizable.
Add a TODO to the special code that sets a size.
Unfortunately there are still some artifacts for some reason, i.e. the title bar still seems to be shown for a maximized instrument window: