MuseScore
MuseScore copied to clipboard
musescore
Use single MuseScore instance for all app windows
Task description
This task proposes a revision to the way MuseScore currently handles multiple open projects in MacOS.
Currently, a new app icon appears in the dock for each opened project window.
This is generally inconsistent with other MacOS apps that also use separate windows for each opened file, and generates both confusing UX and a cluttered UI in the dock.
Please see this design spec for an illustration of how an alternate approach might work for MuseScore 4:
Design-Spec_New-Project-Windows_2Aug22.pdf
Let me know if there are any questions or comments! Bradley
The multiple app icons are forced by the multi-instances thing. One instance of MuseScore can currently open only one file at a time, and almost everything relies on the assumption that there will always be zero or one files open at a time.
It is not possible to have multiple instances of an app but show only one app icon. Running multiple instances of one application is totally against the principles of macOS and thus not supported by Apple, and thus it affects the UX quite badly (multiple Dock icons, multiple icons in the app switcher, the shortcut to switch between windows not working...).
So, as far as I can see, the only way to fix this, is to rewrite significant portions of code so that the app can also handle multiple files within the same instance. (For Windows, we may still need the inter-process communication system, because on Windows it is apparently much more common that multiple app windows live in multiple processes.) I don't think it's realistic that this will be fixed before the release of 4.0.
This is the reason that I've always been silently frustrated by the whole multi-instances thing, but because so far I seemed to be the only one who cares about it, I didn't make a lot of noise about it.
Aha, so @cbjeukendrup is the reason that apps, like Logic and Pages in macOS, succeed in having only one icon in the dock (with multiple files open simultaneously) because they are running "multiple files within the same instance", as opposed to "multiple instances of the one application"?
FWIW this design was actually based on the UX of these two Apple apps, but I wasn't aware that something more fundamental under the hood was the reason our app behaved differently.
If it does require a significant rewrite of code, then I worry this may need to be bumped to 4.x. ☹️
I wasn't aware that "single instance, multiple windows" was a possibility. Perhaps it only works on macOS? Anyway, I think the current multi-instance approach was adopted partly because the new playback system wouldn't work otherwise, or it would require constantly loading and unloaded samples as you switch between scores. I'll be curious to see how that particular problem will be handled if we go back to using a single instance.
I thought "single instance, multiple windows" is a very normal thing and as far as I know, it can work on any OS (and should even be doable with QML). Anyway, on macOS, using a single instance is "the only correct way" to do it.
I've also always heard that the main reason for using multiple instances is something with playback, but I don't know anything more specific than that. Actually, at a first glance, the playback system seems already capable of handling multiple scores, because it works with independent "track sequences".
I think the real difficulty will be UI state handling; some state needs to be handled within individual windows, other things need to be coordinated app-wide. For example, palettes and toolbars would need to be synced between windows. I estimate that it is not really difficult to do, but just requires time to get it right, and it is guaranteed to introduce new bugs. Therefore my feeling is to delay this to 4.x, not just post beta 1. It's regrettable if it causes macOS users to be unhappy with 4.0, but even more delay + a lot of bugs is still more regrettable.
By now I've seen enough remarks/complaints from users to say that the change in behavior has been voiced for the other platforms as well.
@jeetee, is it just that users miss having tabs for different scores in the same app window, or does the technicality of having multiple instances cause problems on other platforms besides macOS? (What are those problems?)
It's (for the other OSes) definitely all about the single windows vs multi-window. I don't think most users out there are even aware of the difference between multi-instance-single-window-single-score and single-instance-multi-window-single-score.
It was more of a statement that (since topic title here mentions MacOS) doing this with the MacOS issues as driving factor will help alleviate some of the complaints about single-vs-multi-window (not necessarily instance, apologies) on the other systems.
Ok right. To be clear, even if we fix the multi-instance problem, it's not certain that we will go back to using a single window with tabs for every opened score. That's more of a design decision rather than a technical problem like this one, so it ought to have its own issue really.
I couldn't easily find a reference in the Human Interface guidelines, although CNET mentions it: On a Mac you never have multiple instances of an app. One instance runs all the windows.
FWIW, the multiple tabs in Musescore 3 is a PITA. The normal Mac way is to have multiple windows. The system will handle you putting them in tabs in a single window automatically.
Personally, the tabs have been useful for doing transposition work and keeping charts in order. I don't know how much work it would take to implement, but IMHO it should be an option to open scores in either a new window or a new tab, depending on what workflow works best for the composer/arranger. That said, even a fix on the multiple instances would be a massive help.
If you'd like to see tabs for score projects back then please open a new issue for it. This issue is about multi-instances.
Tabs come for free with the MacOS, so if you can fix the multi-instance problem, it will fix the tabs at the same time.
Tabs come for free with the MacOS, so if you can fix the multi-instance problem, it will fix the tabs at the same time.
Not in a Qt app, which MuseScore is. At least not in a sensible way. It will look very awful and work badly, because macOS doesn't know about the design and color scheme of MuseScore, and MuseScore can't know when the user presses the "new tab" button that macOS generates, and can't know what to do when the user presses it.
Anyway, please do open a new issue about tabs. From a technical point of view, it's a separate task.
I don't care if it's tabs or windows: the multiple icons in the Cmd-TAB switcher is unlike every other application. That really needs to go. It feels like a bug, not a feature. Or maybe: an implementation detail that should not concern the user suddenly becoming visible to the user.
I'm curious if this is going to be addressed soon? I'm still using MS3 mainly for this reason on my Mac.
That's too bad it's not sooner. I appreciate the update though. Thanks!
I've done some reading into how Chrome handles it's processes, and while we have some different challenges (due to Qt only having one renderThread per QApplication), I believe we could attempt a similar approach in having one Launcher process (with the ipc server) and have every other (GUI)-instance be raised as a child process into it.
Working on a small proof of concept application (without the full burden of porting and refactoring the mu::ipc usage) which hopefully might give us the insight in how to alleviate this Mac annoyance.
See https://github.com/jeetee/Qt_ProcessTree_ipc for the launcher process test project. I'm not too optimistic, as on windows the child processes all do show up as separate top level entries in the task manager, but you never know..
@cbjeukendrup would be nice if you can have a local test build going on somewhere during this or next week. At best, we'll have a fairly limited refactor to fix the dock effect; at worst, we'll at least be aware that a more profound refactoring is necessary.
@jeetee Thanks very much for your efforts! But unfortunately, I have bad news: it still produces multiple Dock icons on macOS. So I think that what needs to be done is that there is always only one QApplication instance, and all QWindows live in the same process as that instance. As long as we do that, we can apply whatever sub-process magic we want, with separate audio rendering processes for example... (like Dorico, by the way) But I'm afraid the conclusion is: a complex refactor will have to be done, regardless of whether we just try to do everything in the same process or use separate processes for audio rendering.
See https://github.com/jeetee/Qt_ProcessTree_ipc for the launcher process test project. I'm not too optimistic, as on windows the child processes all do show up as separate top level entries in the task manager, but you never know..
@cbjeukendrup would be nice if you can have a local test build going on somewhere during this or next week. At best, we'll have a fairly limited refactor to fix the dock effect; at worst, we'll at least be aware that a more profound refactoring is necessary.
The Chrome way is the right way : users are free to use tabs or different windows, and a tab can be simply dragged and dropped in its window. That's the best of both world. I wouldn't worry about each tab appearing as its own process in task manager, that's expected.
I think Chrome deliberately uses separate processes so that if one tab crashes it doesn't bring down the entire program (at least that's how it works in theory...). But it sounds like that approach wouldn't work for us anyway.
I think Chrome deliberately uses separate processes so that if one tab crashes it doesn't bring down the entire program (at least that's how it works in theory...). But it sounds like that approach wouldn't work for us anyway.
Yes that's true, but how wouldn't that work for you? I thought having separate processes was a req for you to manage different sounds? It is a genuine question I'm a IT dev and would like to help if something is doable with my capacity.
I wouldn't worry about each tab appearing as its own process in task manager, that's expected.
It's not about the process appearing, it's about them not appearing as children (even when they are). Take note that if you look at the current MuseScore process, you'll already notice that the crashpad handler exists as it's child process (and is listed as such).
The difficulty here (and why casper and myself were/are testing out some approaches) is to make Q(Gui)Application instances behave according to the Chrome model. If you'll run through the linked test project, you'll notice when running/debugging it already is one top level process with everything else as a child (or child of child) under it. However, due to how QGuiApplications register themselves with the different OSses, each of the initial child processes is still regarded as "top level" by windows (task manager) and MacOS (multiple dock icons, instead of one).
The additional challenge posed (for the "big refactor", which seems a more likely requirement for every other failed path attempt) is that Qt only allows for a single UI renderThread for a topLevel QApplication. This would mean that we'd probably need to come up with an implementation to support multiple renderThreads to re-enable a multidocument interface without making it slower than the current MuseScore implementation. Most likely this means a change to how the ScoreView is implemented to allow it to do buffered rendering instead of inside an existing QML component and then transfer that buffer via Shared Memory to the actual UI renderThread.
Another question that is yet to be answered, is whether the cause of the multiple top-level entries is the presence of multiple Q(Gui)Applications (more likely) or the fact that they each spawn their own QMainWindow (less likely). Though still allowing multiple QMainWindows in a single multi-processed QGuiApplication might still mess with MacOS's unified menubar behavior. If it does, then aside from ScoreView, the normal MainWindow rendering and how palettes/mixer etc are drawn within it will also require an architectural review.
I think the possibilities research can now be pretty much concluded after diving into some more topics around this; with a fairly decent summary in this topic around PyQt and multithreading. I'll summarize the most important takeaways relating to MuseScore here:
-
A process can have only one QCoreApplication or derivative (QApplication/QGuiApplication) of it.
-
The QCoreApplication object must be the 1st QObject created on the "main thread". The "main thread" according to Qt is the first thread that creates a QObject (even if it's not the QCoreApplication). This does not have to coincide with the actual application thread running the main function. Consequence: You can't use a QThread to run a QCoreApplication, as QThread itself is already a QObject.
-
Due to thread affinity of QObjects, the UI really should run within the eventloop of the QCoreApplication. As such there should be only one UI thread and it will be the "main thread".
-
(At least on Windows) Spawning multiple QMainWindows is just fine and likely doesn't enforce multi-dock-behavior on MacOS.
-
The child processes showing up as top level processes in the windows task manager in the ProcessTree test project from above are indeed due to violating the "single QCoreApplication" rule. The way QCoreApplication handles registering itself to the OS enforces them as seperate toplevel processes (but with child-linkage).
-
It is possible to perform (part of) the drawing in a separate thread and doing so in shared memory if that drawing is computationally intensive (see the Qt Mandelbrot Example). Whether or not this is something we'd want to use for ScoreView or not remains to be seen and subject of further analysis (by "someone"). It might already suffice to perform our layoutcalculations on a worker thread while leaving the drawing based on the resulting values within the UI thread.
I'll have a go at working these conclusions (aside from the renderthread approach) into a new version of the ProcessTree repo so we can confirm that his method of single-instance running will address the MacOS docking problem.
Finally got around to updating the example project to be a single (gui) instance build. For which Casper could confirm the desired dock icon behavior on MacOS.
Next steps: Figure out which modules can be loaded/linked to the Single GUI Instance (settings/workspaces come immediately to mind, avoiding the synchronization mess we currently have on them) and which modules are MainWindow-specific (notationcontroller etc).
This does not yet begin to investigate a possible tabbed multi-document single-window approach. Only looking into single instance, multi window to limit/minimize the changes needed for MuseScore.
I'll probably halt development on the separate test project unless something specific needs additional attention and start moving into a MuseScore branch for the bulk of those changes; so we can account for the MuseScore specific interactions and architecture.
I'm having a (slow!) go at trying to modify MuseScore on the main/app/appshell level over at https://github.com/jeetee/MuseScore/tree/12647-single-instance-model . As always, anyone with time is free to pick this up as I can't guarantee free time.
And for those following along in hopes of seeing this fix. What I'm doing now is only the starting step; it'll enforce single instance and multi window behavior. But as many things now assume single instance usage, I'm expecting a lot of things will need further updates/fixing after the initial structural changes.
Two ideas.
- I don’t have MacOS, but in Ubuntu (Gnome) applications can be grouped - one icon, several instances, and there is a menu for managing them. I don’t know how this is implemented, if you don’t do anything, several application icons appear (for example, for MuseScore), i.e. for such a grouping you need to do something. After doing a little research, I couldn't find what should be do for it.. But the idea is that if there is such an opportunity in Gnome, then maybe there is something similar in MacOS. We just need to find out what exactly needs to be done for this.
- We can do a hack. It is possible to show a window without an icon on the taskbar. On the other hand, we always have a IPC server that “knows” about all instances. Thus, we can make the icon appear only for one instance, for the IPC server, and not appear for the rest. All that remains is to decide how to switch to other instances. Probably we can make some kind of menu... Or simulate their display through fake child windows, which, when selected, will actually cause the display of the corresponding instance.
or 3: actually do run a single UI instance?
I see several problems with this:
- Any crash will lead to closing of all open windows without any saves
- This is more difficult to develop, we will need to either clearly understand what is common and what is different... or pass a some context everywhere (which means more bugs for users)
- It's strange to make these complications due to a limitation of one of the platforms