Use single MuseScore instance for all app windows

[bkunda]

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

[cbjeukendrup]

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.

[bkunda]

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. ☹️

[shoogle]

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.

[cbjeukendrup]

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.

[jeetee]

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.

[shoogle]

@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?)

[jeetee]

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.

[shoogle]

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.

[stcinder]

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.

[codemiester]

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.

[shoogle]

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.

[cbjeukendrup]

@igorkorsukov Both options seem a no-go.

1. Such thing doesn't exist on macOS. Grouping of dock icons is not possible.
   You could say each dock icon corresponds to a NSApplication instance, so there should be only one of those (and thus only one process that creates a QApplication).

2. This hack doesn't really solve the problem. You would still see multiple icons in the App Switcher, and OS-wide shortcuts like Cmd+Tab and Cmd+` don't work. There is simply a whole stack of problems that are either unfixable or require even more ugly hacks. This is not sustainable.

It's strange to make these complications due to a limitation of one of the platforms

You could say just as well: when building an app for macOS, it's weird if we don't follow the correct architecture of a macOS app. Literally all macOS apps use one main process.

There are two things that are fine:

• use background processes, if we really want things to be in separate processes. But still, have one process that owns the NSApplication and all windows.
• continue using the multi-process architecture on other platforms, but simply add the possibility to open multiple scores in one process for macOS.

One more remark: the multiinstances architecture is very limiting. For example, "unroll repeats" can't really be implemented now: it should create a score in memory based on the current score in its current state, and open that. That's impossible with the multiinstances thing: you'd need to write the generated score to disk, then create a new instance and tell it to open that score and treat it as a special newly created score. This involves the addition of even more "private" command line options that you actually don't want to exist.
Or what about the extensions framework, where users will expect the possibility to do something similar to "unroll repeats", or wants to perform some action for all open scores (including ones in different instances).
Or what about the Split View feature, that lets you open two scores side by side in one window, or in multiple tabs? This seems simply impossible with the current architecture.

Oh, and there is performance and memory usage. Opening a score doesn't take long usually, but starting up a new instance does take very long (sometimes even more than 20 seconds!). And everything is duplicated in memory for every score that's open (for example Qt libraries that are loaded, and even the executable itself, and boilerplate stuff like the NSApplication instance).

My conclusion: both options have different pros and cons, but the current option is absolutely not that much better than the "proper" way. The proper way has the advantage of being ehm... proper, and gives more possibilities for multi-score features.
I'm not too convinced about the "a crash would affect only one window" argument: in the first place, there should not be any crashes, and in the second place, that's what AutoSave and session restore are for. (Incidentally, the "restore session" feature is basically broken by multiinstances.)

Yes, state management is more difficult with multiple scores in one instance. But I think that's just part of our job. I'd rather work two months on a solution that we can be proud of than two weeks on a workaround that only replaces the problem with 5 other problems.

[igorkorsukov]

I don't agree with these arguments, but I need to think and investigate )
Are all large applications that are not specific to MacOS, for example Photoshop, AutoCAD, MS Office, etc., running many windows in one process..?

[stcinder]

Are all large applications that are not specific to MacOS, for example Photoshop, AutoCAD, MS Office, etc., running many windows in one process..?

Every app does this on MacOS.

[igorkorsukov]

Every app does this on MacOS.

And all these programs support multi-window on MacOS?

Help me figure it out.
For example, I have some Sql Manager, it opens one database.
I want to open another database.
I click on the Sql Manager launcher and the previous instance opens with the database already open.
How can I open another database on MacOS?

[stcinder]

I don’t know about Sql Manager, but most apps you could choose File->Open, or drop the file on the app icon and it will open in a new window.

…

On 3 May 2024, at 18:09, Igor Korsukov ***@***.***> wrote: Every app does this on MacOS. And all these programs support multi-window on MacOS? Help me figure it out. For example, I have some Sql Manager, it opens one database. I want to open another base. I click on the Sql Manager launcher and the previous instance opens with the database already open. How can I open another database on MacOS? — Reply to this email directly, view it on GitHub <#12647 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJDBQLQM5NLZEBDNBLOKWMLZANA2JAVCNFSM55LL3HM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBZGI2TEMBTGIYQ>. You are receiving this because you commented.

[cbjeukendrup]

There are of course apps that support only one open file at a time, because the developer did not take the effort to implement multifile support.
But even the most complicated apps (Dorico, Sibelius, Logic Pro, Xcode) support multiple windows with multiple projects, all within one (main) process.

[shoogle]

Chrome has a separate process for each tab and each extension, plus a single process for all GPU rendering. Though there is probably still a single main process on macOS that communicates with the subprocesses somehow.

Of course Chrome is also known for being a memory hog, but other Chromium-based browsers don't seem to have that problem.

[igorkorsukov]

I made sure that a single instance of multi-window is what works on MacOS.
I don’t think this is a good decision by the MacOS developers; perhaps they made their life easier, but they made life more difficult for millions of other developers.
And I don’t think that this is a good solution for users, yes, we can say “there shouldn’t be bugs” but they have and will always be, we can deny this reality, but it will remain a reality. So, isolated processes are more preferable.

But these are, of course, philosophical thoughts... and everyone has their own arguments.

I'll start investigate how to turn MuseScore into a single-application multi-window

[rpatters1]

While I agree that the current multi-instance implementation is counter to Apple's UX guidelines, I actually like it because you can use cmd-Tab to go between open documents. That has always been one of the major frustrations I've had with Finale (which I mention only because it is the single desktop app I have the most experience with).

I do know about tabs, but I dislike them. They add clutter and occupy real estate.

One of the features of Finale that I like quite a lot is the ability to open multiple windows on the same document. Perhaps this is significant scope-creep, but that turns out to be useful above and beyond viewing different parts. Especially in a multiple-monitor setup.

[cbjeukendrup]

Cmd+Tab is indeed the shortcut to switch between different apps (or app instances); but there is also Cmd+` (i.e. the key next to the Z key) to switch between different windows of the same app (should work with Finale too!). So switching between documents can be done just as easily when everything is in one app instance.

Opening multiple windows of the same score is most likely outside the scope of this issue. But I agree that we should implement this. Ultimately I think we'll want to support all imaginable configurations, like having different files as different tabs in the same window, or side-by-side instead of as tabs, or different files in multiple windows, or the same file in multiple windows; or any combination. It's absolutely not realistic to implement that all at once, but we should keep that in mind when designing a MVP fix for this issue.

[rpatters1]

Cmd+`

Holy smokes. I wish I knew about this before Finale was a corpse! 🤣 (Indeed it works in Finale.)