-
-
Notifications
You must be signed in to change notification settings - Fork 994
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
After closing Song Editor new project loaded ends with empty song editor window (must be closed and opened) #7412
Comments
Checked after "Remove term "blacklist" (#7365)" (2024-07-09 00:02:49) : the same bug. P.S. |
Interestingly the whole window acts strange:
|
@michaelgregorius : Thank You for bug confirmation! Man plan is (Edited 2024.08.13) : somehow compare what happens when Song Editor :
Than change code to make "closed by mouse" and "closed by Ctrl + W" the same as "closed by Ctrl + 1". But how I see: member and maintainer start work - and Your will make this job better and faster ... |
@firewall1110, I am not planning to work on this so please go ahead if you like. Did you find that the three ways of closing the Song-Editor behave differently? |
Quote: "Did you find that the three ways of closing the Song-Editor behave differently?" Yes - if "closed by Ctrl + 1", than new project loaded without bug. (I have wrote this in previous comment). P.S. |
Oh, I missed that. But it is interesting indeed. My suspicion is that closing the window by mouse or with "Ctrl + W" triggers a direct interaction with the sub-window whereas closing it via "Ctrl + 1" will trigger something else which then interacts with the Song-Editor sub-window. And as you have already written this will likely enter a different code path which does not exhibit/introduce the problem. That it's a problem with the subwindow can also be seen with the broken window title of the subwindow.
👍 |
New information:
|
Negative result: In SongEditror.h after void changeEvent( QEvent * ) override; (line ~187) In SongEditor.cpp in ending of file (but in namespace) (line ~1136):
And - nothing changed : the same bug ... P.S. |
My theory is that all Qt children of the Song-Editor window get removed (perhaps even by the Qt framework code) when the sub window is closed via mouse click or Might be worth to check how the window title painting code works. If it uses information about the children to position the title correctly then this would speak for this theory as well. |
It seems mate in 1:
When I change in master this line as it was in pre release - it seems no more bug. But I have to check this in fresh master code : without my inserted code ... |
Some more results. I first thought that the following line in
This method is called for the following four editors in However, I then noticed that in the calling method
Which is a little bit weird because it means that just a few moments later it is decided that the subwindow is not destroyed when it is closed. The reasons seems to be that It might be cleaner to add another parameter of type Adding a destructor implementation for |
It is mate in 1: Editor.cpp line ~151 Quote: "The event handler QWidget::closeEvent() receives close events. The default implementation of this event handler accepts the close event. If you do not want your widget to be hidden, or want some special handling, you should reimplement the event handler and ignore() the event." {Qt 5.12 documentation} Key words are started from "want some special handling" ...
is such special handling. Problem is , that after this mate all fine tuning with Qt::WA_DeleteOnClose will became dead code, which simply do nothing. |
Quote: "This method is called for the following four editors in MainWindow::finalize: Song-Editor, Piano Roll, Pattern Editor, Automation Editor." @michaelgregorius Piano Roll, Pattern Editor and Automation Editor : all have the same bug, but most projects are not saved with this windows opened (so it is harder to reproduce it and mostly not possible "meet" this bug in LMMS usage). Usage off Qt::WA_DeleteOnClose (
(2) is for MainWindow itself; |
Quote: (@michaelgregorius )
How I understand: Good news: it seems, that only this one line will became "dead code" after my "mate in one" . |
@firewall1110 there's a better way of saying "Quote" Just put > at the beginning of the sentence. Makes it easier for readers. Will wrap the sentence in a quote block. For eg:- How it looks:-
|
@Rossmaxx ! Thank You for hint! |
Now my plan is:
is not true. |
So there is not "Mate in 1", "focus defends King".: 1: place notes on the grid. I copy this to keep problems together ... |
Must be
Really mate in 6 . P.S. |
10 day alert :: I am about to make PR that will fix this bug, but may be LMMS team member can do this better and faster |
You do not need to post any alerts here. Just issue a pull request so that it can be evaluated by some team members. |
May be somebody started to work - so I make possible to stop me in this case. @michaelgregorius , You make signal that I can go forward without any wait. |
Ah, so it is intended as some way of synchronization. Unfortunately, I don't have an overview of who's working on what. But to my knowledge it is rather seldom a problem that several people are working on the same thing. However, even if several people are working on a problem sometimes you can even get a solution which is a combination of the individual solutions which is a good thing. |
You are right for new feature issue: I made mistake to not make my own PR for audio recording 2 years ago.
Is my solution without any PR, but I was waiting hoping that somebody else , who is "in LMMS project" (for example You, @michaelgregorius ) makes PR using (and improving) my solution. For bug fix the most difficult part is to find code line, that has bug. Find right solution idea - it is much less difficult. I hope to got it in master after 2 - 3 months ... [And it is OK - I am not in project. Without such barrier project will be ruined .... ] P.S. And good variant sometimes happens: #7504 (so this issue is closed now - not after 2 - 3 months: in October- November as it be if I made such kind of PR; and in #7504 is added one detail: so why I write "faster and better") |
I wouldn't even know where to put it. Please create a PR for it with an explanation of why you think this fixes the bug. This is usually the much harder part of a bug fix. Finding out what causes a problem and then to ensure that the solution does not break anything else what worked before. If it is just a few lines and you can explain it well then it's very likely to make its way into the code base rather quickly. |
O yes ... You need to combine information from Mate in 1: and from mate in 6:
add headers for getGUI() , MainWindow
It is done 2 days ago ...
And for this welcome to PR #7515 ... P.S.
|
System Information
Linux Debian Stable, wine32 on Linux, Windows 10 64-bit
LMMS Version(s)
lmms-1.3.0-alpha.1.667+g1c865843f
Most Recent Working Version
lmms-1.3.0-alpha.1.102+g89fc6c9-linux-x86_64.AppImage
Bug Summary
At start working version (1.102) then compiled master (windows downloads - the same).
https://github.com/user-attachments/assets/b6bc879f-ca66-48ad-b8c0-ec69307458ef
The same bug is with Piano Roll, Pattern Editor, Automation Editor windows: if you will open project, saved in state (only) Piano Roll or Pattern Editor or Automation Editor window opened, just after this type window closed by mouse, this new project will be loaded with this type window in buggy state.
Expected Behaviour
If close Song Editor windows (with mouse or with Ctrl+W) after load another project song editor window should be not empty. Should not be needed to close and reopen it.
Steps To Reproduce
Load any project, close Song Editor window (as on video), open another project - project loading, but result - empty Song Editor window.
Logs
Click to expand
Screenshots / Minimum Reproducible Project
No response
Please search the issue tracker for existing bug reports before submitting your own.
The text was updated successfully, but these errors were encountered: