musescore
Always honor the difference between Close and Quit commands
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
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)
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!
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?
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...)
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.
"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.
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.
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.
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.
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).
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).
BTW just today I found MuseScore (4.3) was repeatedly quitting the whole app when closing just the current score tab - despite there being no other MuseScore windows open anywhere (none showing in the task bar etc.). The only thing there was was some orphaned MuseScore process that was no longer associated with a visible window. After killing that the regular behaviour resumed. No user could reasonably expect to guess the behaviour of clicking on a "tab close" icon based on that.
Perhaps not, but then again, this shouldn't happn in the first place. That is, there shouldn't be orphaned processes, so the more important thing to do now would be to track down how that happened and treat the problem, not the symptom.
My only point is that if we're going to have logic that determines what the behaviour should be when you close a score tab, it needs to be based on something a user can definitely perceive. Whether another process is running is not reliably such a thing. You might even have it running some background long-running command-line task (not really a thing in Windows, where GUI apps and command-line tools almost always have to be separate exes, but definitely true in Linux world).
Oh and btw the reason I was using Tab Close this time was because I'd been mucking around and realised I didn't want to save the changes I'd just made, and I wasn't confident undo would work reliably (as indeed, it doesn't always), so the obvious thing to do was to close the score without saving changes and reload.
Yes, the behavior should and does depend on something perceivable. The fact that in some specific case, an as yet unreproduced and unreported bug led to a discrepancy in this algorithm in no means the algorithm itself is wrong. It just means it would now be good to figure out how to reproduce the bug so it can be fixed. Zombie and processes are a bug completely independent of this issue, so best to open a new one once you have steps to have reproduce that one.
Even if other processes do happen to have associated in-principle visible windows, I'd suggest they're frequently not something a user will notice or be able to see at the point they click on the tab close button. Honestly I can't see how anyone would object if the behaviour was simply "always return to the home screen on closing the score tab", but if there's already another process showing it, switch to that one instead.
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Marc Sabatella @.> Sent: Saturday, August 24, 2024 10:58:48 AM To: musescore/MuseScore @.> Cc: wizofaus @.>; Comment @.> Subject: Re: [musescore/MuseScore] Always honor the difference between Close and Quit commands (Issue #22831)
Yes, the behavior should and does depend on something visible. The fact that in some specific case, an as yet underproduced and unreported bug led to a discrepancy in this algorithm in no means the algorithm itself is wrong. It just means it would now be good to figure out how to reproduce the bug so it can be fixed. Zombie and processes are a bug completely independent of this issue, so best to open a new one once you have steps to have reproduce that one.
— Reply to this email directly, view it on GitHubhttps://github.com/musescore/MuseScore/issues/22831#issuecomment-2307966581, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABI5UALYLN6G2RX66SYRDQTZS7LERAVCNFSM6AAAAABHW5TAE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXHE3DMNJYGE. You are receiving this because you commented.Message ID: @.***>
And yes I'm willing to put my hand up to implement this though I won't really be able to confirm it works on Linux/Mac
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Dylan Nicholson @.> Sent: Saturday, August 24, 2024 1:29:08 PM To: musescore/MuseScore @.>; musescore/MuseScore @.> Cc: Comment @.> Subject: Re: [musescore/MuseScore] Always honor the difference between Close and Quit commands (Issue #22831)
Even if other processes do happen to have associated in-principle visible windows, I'd suggest they're frequently not something a user will notice or be able to see at the point they click on the tab close button. Honestly I can't see how anyone would object if the behaviour was simply "always return to the home screen on closing the score tab", but if there's already another process showing it, switch to that one instead.
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Marc Sabatella @.> Sent: Saturday, August 24, 2024 10:58:48 AM To: musescore/MuseScore @.> Cc: wizofaus @.>; Comment @.> Subject: Re: [musescore/MuseScore] Always honor the difference between Close and Quit commands (Issue #22831)
Yes, the behavior should and does depend on something visible. The fact that in some specific case, an as yet underproduced and unreported bug led to a discrepancy in this algorithm in no means the algorithm itself is wrong. It just means it would now be good to figure out how to reproduce the bug so it can be fixed. Zombie and processes are a bug completely independent of this issue, so best to open a new one once you have steps to have reproduce that one.
— Reply to this email directly, view it on GitHubhttps://github.com/musescore/MuseScore/issues/22831#issuecomment-2307966581, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABI5UALYLN6G2RX66SYRDQTZS7LERAVCNFSM6AAAAABHW5TAE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXHE3DMNJYGE. You are receiving this because you commented.Message ID: @.***>
Even if other processes do happen to have associated in-principle visible windows, I'd suggest they're frequently not something a user will notice or be able to see at the point they click on the tab close button.
Which again is why the proposal has been to simply surface another window in such cases.
Honestly I can't see how anyone would object if the behaviour was simply "always return to the home screen on closing the score tab"
If it is limited to only doing this when literally clicking the “x” on the score tab, not with any of the related commands (“x” on window, File / Close, Ctrl+W), then it’s possibly harmless, albeit inconsistent and non standard and as such bad design. But as explained countless times, people absolutely did complain and with good reason when it was impossible to close windows at all and they ended up with a dozen useless home screens. So it would be crucially important not to mess with these correctly functioning commands. One needs to be able to open a dozen score, close them all one by one, and have one fewer window each and every time.
A better design is certainly possible - one involving a permanent home window, for example - but again, it deserves actual design attention, not hacks to workaround obscure bugs by partially reintroducing behavior that was already soundly rejected as non standard and undesirable.
If you’re looking for a quick fix, why not leave this alone and simply implement a new “close current score” command? Or better yet, a “reload current score”, since it seems that is the only thing you actually want to accomplish by unloading? These would be non-controversial and actually useful to others.
Inconsistent with what? I've already given examples of other applications where closing a tab always causes the same behaviour (and there isn't just one standard across all applications). I don't see why this is a hack at all - all I want is that every time I close the current score tab, it returns me to where I started when I first launched the app, that seems pretty reasonable. While my preference is that it remains in the same process, I'm happy to compromise and accept that if another process is already showing that home page, we reuse that one and close the current process (in principle any other processes showing the home page could automatically shutdown at that point instead, but I'll admit I don't really like that idea, it feels...wrong...).
And no, it's NOT just for "reload score". I also do it when I've finished looking at one score and now want to open another.
I honestly don't care what the commands in the File menu do, I never use them.
And yes of course clicking "X" on the top-level window should always end the current process, that's the only way I ever do it.
Inconsistent with the other operations I mentioned. Maybe it is a defensible inconsistency, but again, that’s a design decision and someone from from the design team should be giving the OK on that.
Meanwhile, again, the idea of littering g the system with useless empty windows every time you close a score was soundly rejected before for good reason, so whatever new design you propose must be sure not to do that. And individual issues in the tracker remain the wrong place for design discussions.
Turned out there was already functionality in place to do all the hard work here, it was just slightly buggy (wouldn't reliably determine that there was an instance with no open score), and wasn't being used for the case of determining what to do on file-close. PR addresses both, so it's now impossible to end up with multiple musescore instances showing home screen unless you explicitly launch them from your O/S.
I just realised that File|New is actually broken though (and was in 4.4, probably 4.3 too) - it checks for another process without a score loaded, and switches to it, but you never see the file|new dialog or a new score opened. Has been confirmed on Linux too (thanks, Marc). Should I fix this? That would basically mean getting rid of that logic to try to switch another process not showing a score, and just ensuring that cancelling from File|New always exited the process in that case (but not in the case the current process is showing the home screen and File|New executes within that process)
Proposed fix for File|new that's a small change and I've tested:
a) if you already have a score open, File|New always launches a new process and shows the File|new dialog there b) if you cancel out of file|new, it looks for another instance without a score open, and if there is one, switches to that and exits the current one, otherwise leaves the home screen showing in the new instance
I won't say it's the way I would have designed it but it's definitely better than the current situation, and preserves the existing behaviour where cancelling out of the File|New dialog always returns to the home screen. The other (I'd think better) alternative is that File|New looks for an existing instance without a score open and sends it an explicit request to show that dialog.
It's actually worse than that because if you have several instances with no project open (e.g. launched from your O/S with no filename), then from an instance that does have a file open you use "file|new", it actually brings all the instances with the home screen to the foreground! And in fact, that problem also exists with my PR if you close the score tab. Looking at how to fix, but it doesn't seem there are any cases currently where we try to ensure only a single instance receives a request.
OK, I have a solution that means that only a single instance will respond to the request to bring the window to the foreground, or show file-new, just need to check with @igorkorsukov if he's happy with it. However...from a user POV I'm not convinced it's 100% ideal, because you might have an instance on one monitor with no score open, whereas the instance with a score open that you're working with is on a different monitor. In that case, using File|New (or close tab) now reliably causes the instance on the other monitor to come to the fore, and show the File|New dialog where applicable. It's still a vast improvement on the current behaviour, but maybe it could be improved further with a bit more thought...
Also just tried the following, which also feels a bit...unexpected:
a) have at least 3 open instances of musescore, such that only 1 has a score open. b) from the instance that has a score open, do File|New - one of the other instances is brought to the fore and File|new is shown (good) c) now repeat step b) - from the instance that has the score open, do File|New again. Now it's unpredictable what might happen - either the instance that's already showing File|New comes to the fore, OR the other instance just showing the home screen might open up another File|New dialog. If they're on different monitors, it basically means you can't predict which monitor will show the File|New dialog.
Again, not terrible, but...just something to think about.