Always honor the difference between Close and Quit commands

[jeetee]

Your idea

Ensure that issuing File > Close / Ctrl/Cmd+W only closes the currently open file and not the instance.
Currently the Close command always quits the current instance except for the last one; where Close works as expected.

In the last/only instance, closing the file brings you to the Home page as expected.

Problem to be solved

UX consistency.
When I close the currently opened file, I expect only that action to be executed, keeping the instance available for immediate opening of another score or creation of a new one. Without having to go back to another instance, navigate to its Home screen, loading/creating the score I need and then having to navigate back to that instance to place it back onto the Score view where it already was.

If I wanted to close the instance/window, I would've issued the (already and in parallel existing) Quit command instead.

In addition I'd like to add a "close all" command for closing all instances in one go.

Prior art

No response

Additional context

No response

[MarcSabatella]

Seems like it was that was the case at one time early on, but it wasn't better - if you opened 10 scores than closed them all one by one, you'd end up with 10 open-but-empty instances. Maybe better if there were three different commands:

• close score
• close window
• quit MuseScore (close all windows)

[rgreen5]

I encounter this bug in every session, usually after opening several scores in succession in one MS4 instance. When I click on the close score command, the program closes instead!

[cbjeukendrup]

To be clear, this is not a bug but a feature. As Marc says, if the window stays open, you end up with an ever growing collection of empty windows unless you close them manually.

What we can do to make it feel less like a bug, is bringing the last-used other window to the front when closing a non-last window. That is also what for example macOS normally does, i.e. when all windows are in the same process. So, the logic would become:

When the user closes the last tab in a window (which currently means "closes the masterscore a window", because a window can still contain only one masterscore):

• If it was the last window, keep the window open but switch to the home page
• otherwise, if there is still some other window open, bring that into focus

That way, you can still always easily open another score after closing one. Is that a good compromise?

[cbjeukendrup]

If I wanted to close the instance/window, I would've issued the (already and in parallel existing) Quit command instead.

In addition I'd like to add a "close all" command for closing all instances in one go.

The "Quit" command closes all open instances (at least, is supposed to...)

[MarcSabatella]

The way you describe it is indeed the way it works most of the time, and it makes sense to me. However, I do believe I have seen cases where Close does actually attempt to quit the whole program. I'm never able to be be totally sure as it's possible I just hit the wrong shortcut (they are adjacent, after all). And I have no idea what conditions might reproduce it. Could have something do to do with some instances being opened by double-clicking a score within a file manager and others opened from within MuseScore?

I have not ever seen Quit fail to try to close all windows/scores/instances.

Anyhow, as for proposal to bring another window into focus open closing one: I guess that could help a little, but for me it's not the extra fraction of a second it takes to switch to another window in preparation for opening another score that I would be concerned about. It's the many seconds it takes to actually start a new instance of MuseScore. That is why it might be nice to sometimes be able to keep the current instance when closing a score even though it isn't the last window.

I don't know if it is actually possible, but what if the logic for deciding when to keep a window open after closing the masterscore wasn't based on being the last window, but the last non-empty window? So you wouldn't end up with multiple empty windows after closing a bunch of scores, but you'd have one. This would allow you to more easily finish one score and open or create another another in the same window, even in cases where there happen to also be other open scores.

[wizofaus]

"What we can do to make it feel less like a bug, is bringing the last-used other window to the front when closing a non-last window"

To me that's not helpful - the only reason I use the "close score" command is a) to discard some changes I made since I last saved or b) to ensure that some unusual or unexpected behaviour I'm trying to understand continues even after closing/reopening the score (I do this a lot, i.e. several times a day). I.e. in both cases I want to keep the current instance of MuseScore running, and show me a screen I can easily re-open the score I just closed from.

FWIW I do NOT expect "quit" to close all instances of MuseScore - I personally expect them to be all independent. If I want to close them all, e.g. to install an update or whatever, I'll do it from the Windows task bar (Close all windows) - I assume Mac/Linux have equivalent commands.

I don't believe I have any modern Windows applications with the equivalent of MuseScore's "quit" command, nor have I ever felt the need for it.

[MarcSabatella]

To me reopening the score you just closed should virtually never happen. The only reasons I can see for it have to do with working around bugs, and much better to just fix the bug that implement a special behavior only useful for debugging purposes. Much better to focus on the real world cases for closing scores that are not related to debugging.

[wizofaus]

I assume you mean "should virtually never happen" - and in principle I'd agree, but the reality is MuseScore 4 still does exhibit a lot of behaviours that require playing around a bit to work out what's going on, and closing & re-opening the score you're working on is my "go-to" action in such cases. Providing there are no other instances of MuseScore running, it works fine. But at the point I use that close command, I'm not thinking about whether there are other such instances running, they're possibly on different monitors, behind other windows etc. etc. The behaviour currently feels inconsistent because of this, and personally I don't really see why other instances of MuseScore I happen to have open should affect (or be affected by) the one I'm currently focused on.

[MarcSabatella]

The idea is that then you could easily open another score if you wanted, whereas now you can’t. And as noted already, leaving the window open after closing the score is not good because you end up with lots of empty windows lying around. Hence my suggestion that we try to see if there is a way to make sure only one such empty window exists at a time.

[wizofaus]

Well sure, if there was a spare MuseScore instance lying around that was just showing the "no scores open" screen, and it switched to that instead I wouldn't have an issue with that. But if I've completely finished with what I'm working on and want to close it, I'd expect to just close the whole instance via the window-close button (top right X on Windows, or Alt+F4), which does indeed do what I expect (and appears to be different to what you can do from the File menu commands).

[wizofaus]

FWIW the fix to ensure file-close (i.e. just close the currently open score) always behaves the same regardless of what other MuseScore instances you have running is super simple, and is something I'll be using in my own builds, as if for nothing else when troubleshooting bugs I'm looking at I find it essential to be able to close and reopen a score without killing the process that the debugger is attached to (and I virtually always have other MuseScore instances running).
Would love to it see it supported via an internal configuration flag (e.g. project/fileCloseNeverExitsApplication or similar).