1.2.1 installer by default created "LMMS 1.1.3" Start menu folder

[JeffSoraRiku]

Bug Summary

By default, when asked to create a start folder in windows environment, the installer shows that it will create a folder named "LMMS 1.1.3" by default. it might be a problem exclusive problem of my system language but i cant check it.

Steps to reproduce

1. Download Windows 64bit version in lmms.io (lmms-1.2.1-win64.exe)
2. Start the installer, follow the steps (installer display language: Traditional Chinese)
3. When asked the name of the Start folder to be created, it is shown that "LMMS 1.1.3" is to be created
4. If left unchecked, indeed it will create a Start folder as LMMS 1.1.3

Expected behavior

By default, it should show user that it is trying to create a start menu folder named "LMMS 1.2.1" (or respective version)

Actual behavior

Shows that "LMMS 1.1.3" is to be created as a start folder

Screenshot

https://imgur.com/a/7SkFe2x

LMMS version used

1.2.1 win64

Logs

[DomClark]

CPack/NSIS saves the chosen Start Menu folder in the registry, and uses this as the default folder for future installations. If 1.1.3 was installed previously, then "LMMS 1.1.3" will be suggested as the Start Menu folder. The name of the default folder to be used if no previous folder is saved is the same as the installer title, i.e. "LMMS <version number>".

There are a couple of way we could address this:

• Disable saving the chosen Start Menu folder. This requires that the MUI_STARTMENUPAGE_REGISTRY_* definitions are omitted from the NSIS script, which involves copying and customising CPack's NSIS.template.in. I don't like this option as it isn't as convenient for upgrading LMMS, and will leave Start Menu folders for older versions hanging around.
• Omit the version number from the Start Menu folder. This can be done by omitting it from the installer title, or by defining MUI_STARTMENUPAGE_DEFAULTFOLDER in CPACK_NSIS_DEFINES.

[tresf]

Re-milestoned for 1.3.0. This "bug" has been around for literally ever. It's always existed in every LMMS version ever. Workaround as indicated: uninstall first.

[Rossmaxx]

Omit the version number from the Start Menu folder. This can be done by omitting it from the installer title, or by defining MUI_STARTMENUPAGE_DEFAULTFOLDER in CPACK_NSIS_DEFINES.

@DomClark if you don't mind, can you elaborate?

[Rossmaxx]

Was in the middle of typing but tapped "close with comment" accidentally

[DomClark]

The installer title is controlled by CPACK_NSIS_PACKAGE_NAME, which defaults to CPACK_NSIS_DISPLAY_NAME if the latter is set but not the former. We set the latter to "${PROJECT_NAME_UCASE} ${VERSION}", which evaluates to something like "LMMS 1.2.1" or "LMMS 1.1.3". The Start Menu folder is controlled by the NSIS symbol MUI_STARTMENUPAGE_DEFAULTFOLDER, which defaults to the installer title.

We can:

1. Define MUI_STARTMENUPAGE_DEFAULTFOLDER to ${PROJECT_NAME_UCASE} in CPACK_NSIS_DEFINES, to set the default Start Menu folder to "LMMS". This will ensure an appropriate generic folder from now on, but won't retroactively fix incorrect saved defaults.
2. Remove ${VERSION} from CPACK_NSIS_DISPLAY_NAME, thereby removing the project version from the installer title, the entry in the "installed apps" list in the control panel, and the Start Menu folder. This also won't fix anything retroactively, but offers consistency between the default installation directory, installer title, and app list entry, at the cost of not showing the version in the installer.
3. Set CPACK_PACKAGE_INSTALL_REGISTRY_KEY to change the registry key used to save the chosen Start Menu folder. We could make this version-dependent, to ensure the saved folder isn't used for other versions, or change it once in combination with (1) or (2) to make those fixes retroactive.

I don't particularly like (2) - we lose some information from the installer, and consistency isn't that important - any users who care about the Start Menu folder can change it themselves. (1), possibly along with (3), seems reasonable if we decide that we encourage running a single version, and that the installer will overwrite old versions by default. (3) alone makes more sense if we want newer versions to be installed alongside older ones. We could even include the build type (stable, beta, nightly) in the Start Menu folder and registry key, so users can upgrade a testing version without replacing a stable version by default.

It's worth noting that CPACK_NSIS_DEFINES isn't a publicly documented CMake variable: it's designed for internal use, and will conflict with a component-based installation, should we ever choose to do that. However, we are already using it, so adding things to it won't make anything worse for now.

[tresf]

My vote:

1. No version in the start menu name
2. Delete old cruft

The deletion of the cruft will be tricky, either we hard-code each installation version we've ever used, or use some matching technique, which can be tricky in the NSIS language -- and even moreso when conflated by CMake.

[Rossmaxx]

My vote is actually to not use the registry. Is it possible to not use the registry at all (and make way for a portable install at a later point).

[tresf]

My vote is actually to not use the registry.

By default, Windows tracks installers using the registry for both user-wide installs or system-wide installs. This allows a person or organization to quickly list and remove software on the computer. This is the recommended method by Microsoft.

Is it possible to not use the registry at all (and make way for a portable install at a later point).

Yes, however this is off-topic for this particular thread. You may create your own portable installer at any time, but it should be tracked as a separate issue.

LMMS is currently relocatable, however file associations (e.g. .mmpz) won't register, so you will need to open projects manually. Here's an example of a manual method for running LMMS without installing using 7zip: Install LMMS without Admin. PortableApps.com leverages NSIS as its installer technology (which we already use), so adding this should be rather trivial.