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