with Qt equivalents qgetenv/qsetenv and if supported the newer qEnvironmentVariable().
I am also replacing hard-coded paths, like for example the all-important config location in globals.cpp:
Code: Select all
QString configName = QString(getenv("HOME")) + QString("/.config/MusE/MusE.cfg");
Also the plugin cache path will use the same function to look up the correct user cache location on the OS.
I incorrectly put the cache files in ~./config/MusE/scanner when it should have been ~./cache/MusE/scanner (on Linux).
Also, I want to replace all 18 calls to QSettings("MusE", "MusE-qt") with the nifty new convenience feature in Qt 5:
Call QApplication::setApplicationName() and setOrganizationName(), and then all calls to the new QSettings() constructor
automatically fill in the organization name and application name with those set values.
These QSettings were added at some point in our Qt4 history. The reason we had to do it that way is unique to MusE: We already
had a configuration file named "MusE.cfg". Thus the author decided best to call the QSettings app name "MusE-qt" to avoid confusion,
otherwise we would have both "MusE.cfg" and "MusE.conf" in the same folder. So instead it's called "MusE-qt.conf".
So I tried QApplication::setApplicationName("MusE-qt") and setOrganizationName("MusE") so that the new QSettings() constructor works.
I also call QApplication::setOrganizationDomain("muse-sequencer.org"). See the docs about Mac preferring the domain over org name.
But... I've reached a problem, convoluted so stay with me:
When I use QStandardPaths before the QApplication is instantiated, the <APPNAME> portion of the various returned paths is blank (see docs).
After the QApplication is created, the <APPNAME> is filled with the application name (which defaults to exe name since Qt 5).
This makes sense, I suppose. Certain OS example paths in the given chart need that APPNAME. Seems undocumented though.
But... Also seems undocumented, QStandardPaths::writableLocation() actually returns paths that include the organization name.
Thus if I ask for the new-ish 'AppConfigLocation', I get ~./config/MusE/MusE-qt.
So, yes there are ways I can get around make it exactly like it is now without changing config locations.
I can ask for the older 'GenericConfigLocation' and tack on our organization name ie. "~./config/MusE".
But... Here's my dilemma: I would really like to let Qt compose the 'full' path for much ease and to be consistent
ie. "~./config/MusE/MusE" or "~./config/MusE/MusE-qt" or say "~./config/MusE/MusE-seq".
That way:
a) I won't have to use QSettings("MusE", "MusE-qt") or whatever, just QSettings().
b) QStandardPaths will just work, using the app name and organization name or domain.
c) Consider if the "MusE" organization were to produce a second app, it would then go to "~./config/MusE/FancyNewApp".
(Note that wherever you see strings like "MusE", I've really moved them all into our config.h file to be a central place
housing string literals like our organization name, package name, app name, domain, and/or QSettings app name. All as #defines.)
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
To do so I MUST move our configuration and cache locations to the above mentioned places.
I will of course make it copy existing config and cache files to the new locations, such as user-defined instruments, cache files, settings etc.
This would be a one-time trick when you first start MusE with these changes applied.
Here I must warn that is then NOT backwards compatible with older MusE versions.
Starting an older version will not find any config stuff and thus start from fresh.
But I could leave the old config files in place so that older versions can use them (heck it will write there anyway!)
but of course the older versions won't find anything new that you add to the new config location.
Whew. Hopefully we'll sort this out.
But if there are any objections or views on the situation, speak up.
Just warnin' y'all. I might go ahead and do it. Time is short.