Effect/instrument window positions are not saved

[regulus79]

System Information

Arch Linux, GNOME

LMMS Version(s)

master

Most Recent Working Version

No response

Bug Summary

If you open any instrument/effect control windows, move them around, and then save the project, when you reopen the project the effect windows will all be closed. And when you go to reopen them, they do not appear in the same place.

This is in contrast to the default windows, such as the Song Editor or the Piano Roll, which keep their position between sessions.

Expected Behaviour

When saving a project, the position and visibility of all windows should be saved.

Steps To Reproduce

1. Create a new project
2. Add an effect/instrument
3. Open the effect/instrument's controls window
4. Move it around, and save the project
5. Reopen the saved project
6. The window is not visible, and not in the same place.

Logs

Screenshots / Minimum Reproducible Project

No response

Please search the issue tracker for existing bug reports before submitting your own.

• I have searched all existing issues and confirmed that this is not a duplicate.

[sakertooth]

My guess is that since the tracks are being deleted even when reopening projects, the windows will have to be closed and deleted as well (not hidden). The Song Editor and Piano Roll persist because they do not have to be closed between sessions as they are not session specific.

For example, PianoRoll is stored and created within GuiApplication:

...
	displayInitProgress(tr("Preparing piano roll"));
	m_pianoRoll = new PianoRollWindow();
	connect(m_pianoRoll, SIGNAL(destroyed(QObject*)), this, SLOT(childDestroyed(QObject*)));

[sakertooth]

That being said, I don't think this is an issue worth fixing, because then that would mean the windows should not be closed and deleted, and the tracks can't get deleted as well. People would expect reloading the project to close and clear out everything, and then load it in again.

[sakertooth]

Oh, I see what the idea is now. You want to save window positioning state as well as the actual state of the tracks.

When saving a project, the position and visibility of all windows should be saved.

I don't think this is a good idea because it wouldn't work when opening a project with different computers that have different displays. For example, if one project stored on one computer had a certain resolution, and you opened the project with a different computer on a different resolution, you would have to scale that window position to match the new display, which will involve storing the state of the resolution of the other monitor.

Projects should not depend on storing this kind of state as its quite unorthodox and possibly error-prone.

[regulus79]

I was thinking the state of the windows would be stored in a similar way as the piano roll and the other editors, either as attributes to the instrument/effect nodes, or as separate nodes.

<pianoroll y="1" height="480" width="970" maximized="0" stopbehaviour="0" minimized="0" x="1" visible="0"/>

That way the windows would all still get reloaded when you load a project.

I don't think this is a good idea because it wouldn't work when opening a project with different computers that have different displays.

I guess that might be true... but isn't that how the piano roll, automation editor, projects notes etc. work currently? Since only the position and size of the editor windows are saved, I think if you open a project on a bigger screen they would be in different places (?)

[sakertooth]

I guess that might be true... but isn't that how the piano roll, automation editor, projects notes etc. work currently? Since only the position and size of the editor windows are saved, I think if you open a project on a bigger screen they would be in different places (?)

I wasn't aware we are actually already doing something like this...

[sakertooth]

The coordinates could be completely invalid/out of bounds when opening the project on a different monitor. If we don't properly handle this, why are we doing it?

[sakertooth]

Maybe if we store relative coordinates instead of absolute screen coordinates, the problem would be solved, but that's possibly going into the territory of a separate issue entirely. They would also have to be stored separate from <instrumenttrack> and in something like <instrumenttrackwindow> with some linkage back to the track it represents. This is because InstrumentTrack's do not store GUI related information as they are in the Core.