Check major/minor version before setting artwork directory

[tresf]

I believe we should put a check in our themes/artwork loading logic to check that the major and minor version of the software matches that of the config file prior to using a custom theme directory.

I recommend this because the themes directory is volatile to many usability-breaking changes and we should prioritize a working theme when we have a good idea the theme will break (which historically seems to be consistent with our minor versioning)

This is compat code, but it would be scalable (not bound to any specific version) but would ensure any terribly oudated .lmmsrc.xml file does not try to use artwork from a completely different version of the software, addressing #1187 moving forward.

I believe the best approach is to set m_artworkDir to defaultArtworkDir() if VERSION_MAJOR + VERSION_MINOR !== value( "lmms", "version" )

• ^-- (pseudo code, we'll have to snag the "version" attribute from the dom and also chomp off VERSION_PATCH before we do our string comparison.

I think this will tremendously improve the upgrade experience for users which have old custom themes, or have reinstalled newer LMMS versions over an older version with the theme defaulting to a different location (i.e. Program Files (x86) versus Program Files (x86))

This is not a replacement for proper uninstalling... We may still encounter compatibility issues when the old version is not uninstalled properly, but from my experience, this is something even the developers encounter when switching branches and running the software, so it should be a fix that we can keep around for years to come.

https://github.com/LMMS/lmms/blob/stable-1.1/src/core/config_mgr.cpp#L294

[tresf]

Per #1442, I think I have this working nicely. Test results:

Here's a 1.0 theme running on 1.1 (obviously broken)

Test 1 I edit the config to reflect a different major version number

Test 2 I edit the config to reflect a different minor version number

I relaunch LMMS, and it resets to the default theme. (both test results pass with the same results)

Not depicted:

• Test 3: Keep major/minor/patch the same (Pass - Old theme was loaded)
• Test 4: Change patch version only (Pass - Old theme was loaded.)
• Test 5: Delete ~/.lmmsrc.xml file (Pass - New theme was loaded.)

@Sti2nd @musikBear @Umcaruje This should fix all of the piano roll anomaly reports we keep getting.

[tresf]

Closed via #1442

[Umcaruje]

This is an awesome solution to this problem 👍

[Sti2nd]

This is an awesome solution to this problem

I wouldn't know.

[Umcaruje]

One drawback I can see is when one uses multiple LMMS versions on the same machine (like I do). Opening a different version version would always force to the default theme.

[tresf]

Opening a different version version would always force to the default theme.

Yeah, we don't support that for our end-users, so this is intended, but for your very specific purposes, I would recommend shimming a config backup/restore process into your launcher, or write a python script which fakes the version info via a quick hack XML DOM writer.

In the future we may entertain a different approach to the config filename, but as long as it is shared between versions, we have to assume the theme will break-cross-major-minor-version.

Furthermore, if you change the version number in CMakeList.txt to match prior to compiling, you can trick it to think they're the same version anyway, right?

-Tres

[Umcaruje]

Yeah, we don't support that for our end-users, so this is intended, but for your very specific purposes, I would recommend shimming a config backup/restore process into your launcher, or write a python script which fakes the version info.

Or, instead of putting my theme in a specific folder, I can overwrite the default theme. That's another solution :)

[tresf]

Symlink? :)

[Umcaruje]

Symlink? :)

No, just delete the themes/default directory and rename my theme dir to 'default' and repeat every time I recompile :3