Start GUI without a splash screen

[irwir]

Your idea

Add a command line option to prevent showing splash screen on startup.

This should be much simpler than GUI implementation of the same feature (no graphical controls to draw, no localization).

Problem to be solved

Search expressions having "disable splash screen" together with an application name are quite popular in the net. This is because logos, splash and welcome screens after a while are felt more like nag screens. Hence many applications provide ways to bypass splash screen display (for example: Visual Studio, Libre/Open Office).

Additional context

Implementation should be straightforward; only 6 lines of code unless something important was misunderstood or overlooked. (I could try a pull request, but the code would be untested - no development environment had been installed.)

1. commandlineparser.h - add a variable

struct Options {
...
        struct {
...
            std::optional<bool> nosplash;
        } startup;
    };

2. commandlineparser.cpp - add parsing code

   
   m_parser.addOption(QCommandLineOption("nosplash", "Prevent showing the splash screen"));
   ...
   if (m_parser.isSet("nosplash")) {
       m_options.startup.nosplash = true;
   }

3. `app.cpp` - add "nosplash" option check:
`    if (runMode == framework::IApplication::RunMode::GuiApp && !m_options.startup.nosplash) {`

[Jojo-Schmitz]

In Mu3 you could disable the splash screen in Edit > Preferences. No longer in Mu4 > Regression!

[irwir]

Thanks for the input. I have never used v3, but disabling option should exist as either GUI or command line implementation. Portable application seems had a parameter in .ini to disable splash screen, but it had no effect on regular application when added to its .ini file.

[Jojo-Schmitz]

best_ having both

As far as I can tell there is a setting for this, "ui/application/startup/showSplashScreen", for the ini file, it doesn't work though, seems a leftover from Mu3

[irwir]

best_ having both

Command line, GUI and .ini file. Did you mean all three? :) Seriously, even two would be an overkill. GUI is the simplest to use in all OSes. Do you plan to restore this capability as in PR for bringing back Save button? Otherwise, command line option should be trivial to add yet still do the job.

[Jojo-Schmitz]

Well, GUI and ini-file are the same thing really. At least should be. And no, I do not plan to work on it, esp. not as part of the Save button PR.

[Eism]

It's interesting to understand the rationale behind adding such an option in Visual Studio Code. Maybe it's just legacy. A splash screen serves as more than just a visual element, it indicates that the program has been initiated and is running smoothly, preventing the perception of the program being stuck.

Additionally, it would be beneficial to gauge the demand for this feature among MuseScore users.

[Jojo-Schmitz]

It isn't a new feature, but a regression vs. Mu3

[irwir]

It's interesting to understand the rationale behind adding such an option in Visual Studio Code.

Who said Code? Just Visual Studio, including the curent VS 2022. The rationale for disabling splash screens you might have missed in the opening message of this issue. Those who like the splash would not disable it.

[irwir]

@Jojo-Schmitz

Well, GUI and ini-file are the same thing really. At least should be. And no, I do not plan to work on it, esp. not as part of the Save button PR.

As a side note, some features might be restricted to .ini file only. And I wrote "as in PR for..." meaning a similar, but separate PR. If nobody is going to work on GUI implementation, does it make sense to go on with this command line option idea?

[MarcSabatella]

No program should ever require you to edit an INI file or even know that it exists. The INI file records the effect of a change you make, but the change itself should be made in the UI, via command-line option, or whatever other means.

It's an obscure rare thing for anyone to want to do, so in my opinion, merely adding support for this in Edit / Preferences ./ Advanced should be more than sufficient. Making it a command-line option only would be an almost complete waste of effort; the vast majority of users would have no clue how to access this. if it's worth doing, it's worth making visible. if there is a use case for making it a command-line option in addition, so be it.

You can test your own PR without a build environment. Submit the PR, wait for the automated build to complete, download the build artifact for your OS. I normally do this on my own fork to avoid stressing the main build environment.

[irwir]

Since the subject of this FR is marked as a regression, probably GUI option is to be restored (maybe) and there is no need to go on with a command line option. If this was a startup option in v3 (PREF_UI_APP_STARTUP_SHOWSPLASHSCREEN), then it is expected to go to General preferences as other startup flags, not to Advanced.

No program should ever require you to edit an INI file or even know that it exists.

Very interesting remark from a Debian user. :) A follow-up of the idea would be the necessity to add command line equivalents for all options, because early crash may prevent access to GUI dialog with settings.