2013-02-25 20:22:07 +00:00
|
|
|
#include "gamesettings.hpp"
|
|
|
|
|
2013-01-26 17:19:04 +00:00
|
|
|
#include <QDir>
|
2023-01-10 18:12:13 +00:00
|
|
|
#include <QRegularExpression>
|
2013-01-25 04:19:06 +00:00
|
|
|
|
2013-01-26 17:19:04 +00:00
|
|
|
#include <components/files/configurationmanager.hpp>
|
2022-08-19 22:33:51 +00:00
|
|
|
#include <components/files/qtconversion.hpp>
|
2023-01-12 11:39:50 +00:00
|
|
|
#include <components/misc/utf8qtextstream.hpp>
|
2013-01-26 17:19:04 +00:00
|
|
|
|
2020-04-26 13:31:39 +00:00
|
|
|
const char Config::GameSettings::sArchiveKey[] = "fallback-archive";
|
2015-01-10 05:46:47 +00:00
|
|
|
const char Config::GameSettings::sContentKey[] = "content";
|
2020-04-26 13:31:39 +00:00
|
|
|
const char Config::GameSettings::sDirectoryKey[] = "data";
|
2013-01-25 04:19:06 +00:00
|
|
|
|
2023-01-08 18:02:03 +00:00
|
|
|
namespace
|
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
template <typename T>
|
|
|
|
QList<T> reverse(QList<T> values)
|
2023-01-08 18:02:03 +00:00
|
|
|
{
|
|
|
|
std::reverse(values.begin(), values.end());
|
|
|
|
return values;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-03-21 20:27:25 +00:00
|
|
|
Config::GameSettings::GameSettings(const Files::ConfigurationManager& cfg)
|
2013-01-26 17:19:04 +00:00
|
|
|
: mCfgMgr(cfg)
|
2013-01-25 04:19:06 +00:00
|
|
|
{
|
2024-03-31 23:15:58 +00:00
|
|
|
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
|
|
|
|
// this needs calling once so Qt can see its stream operators, which it needs when dragging and dropping
|
|
|
|
// it's automatic with Qt 6
|
|
|
|
qRegisterMetaTypeStreamOperators<SettingValue>("Config::SettingValue");
|
|
|
|
#endif
|
2013-01-25 04:19:06 +00:00
|
|
|
}
|
|
|
|
|
2013-12-24 23:50:25 +00:00
|
|
|
void Config::GameSettings::validatePaths()
|
2013-01-25 04:19:06 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QList<SettingValue> paths = mSettings.values(QString("data"));
|
2013-01-26 17:19:04 +00:00
|
|
|
|
|
|
|
mDataDirs.clear();
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
for (const auto& dataDir : paths)
|
2022-08-19 22:33:51 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
if (QDir(dataDir.value).exists())
|
2024-03-15 00:42:15 +00:00
|
|
|
{
|
|
|
|
SettingValue copy = dataDir;
|
|
|
|
copy.value = QDir(dataDir.value).canonicalPath();
|
|
|
|
mDataDirs.append(copy);
|
|
|
|
}
|
2013-01-26 17:19:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Do the same for data-local
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
const QString& local = mSettings.value(QString("data-local")).value;
|
2013-01-26 17:19:04 +00:00
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
if (!local.isEmpty() && QDir(local).exists())
|
2024-03-15 00:42:15 +00:00
|
|
|
{
|
|
|
|
mDataLocal = QDir(local).canonicalPath();
|
|
|
|
}
|
2013-01-26 17:19:04 +00:00
|
|
|
}
|
|
|
|
|
2024-02-27 14:11:48 +00:00
|
|
|
QString Config::GameSettings::getResourcesVfs() const
|
2020-04-26 13:31:39 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QString resources = mSettings.value(QString("resources"), { "./resources", "", "" }).value;
|
2024-02-27 14:11:48 +00:00
|
|
|
resources += "/vfs";
|
|
|
|
return QFileInfo(resources).canonicalFilePath();
|
2020-04-26 13:31:39 +00:00
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QList<Config::SettingValue> Config::GameSettings::values(
|
|
|
|
const QString& key, const QList<SettingValue>& defaultValues) const
|
2013-01-26 17:19:04 +00:00
|
|
|
{
|
|
|
|
if (!mSettings.values(key).isEmpty())
|
|
|
|
return mSettings.values(key);
|
|
|
|
return defaultValues;
|
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
bool Config::GameSettings::containsValue(const QString& key, const QString& value) const
|
|
|
|
{
|
|
|
|
auto [itr, end] = mSettings.equal_range(key);
|
|
|
|
while (itr != end)
|
|
|
|
{
|
|
|
|
if (itr->value == value)
|
|
|
|
return true;
|
|
|
|
++itr;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Config::GameSettings::readFile(QTextStream& stream, const QString& context, bool ignoreContent)
|
2013-12-16 19:40:58 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
if (readFile(stream, mSettings, context, ignoreContent))
|
|
|
|
{
|
|
|
|
mContexts.push_back(context);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
2013-12-16 19:40:58 +00:00
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
bool Config::GameSettings::readUserFile(QTextStream& stream, const QString& context, bool ignoreContent)
|
2013-12-16 19:40:58 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
return readFile(stream, mUserSettings, context, ignoreContent);
|
2013-12-16 19:40:58 +00:00
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
bool Config::GameSettings::readFile(
|
|
|
|
QTextStream& stream, QMultiMap<QString, SettingValue>& settings, const QString& context, bool ignoreContent)
|
2013-01-26 17:19:04 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QMultiMap<QString, SettingValue> cache;
|
2024-02-27 01:39:49 +00:00
|
|
|
QRegularExpression replaceRe("^\\s*replace\\s*=\\s*(.+)$");
|
2023-01-10 18:12:13 +00:00
|
|
|
QRegularExpression keyRe("^([^=]+)\\s*=\\s*(.+)$");
|
2013-01-26 17:19:04 +00:00
|
|
|
|
2024-02-27 01:39:49 +00:00
|
|
|
auto initialPos = stream.pos();
|
|
|
|
|
|
|
|
while (!stream.atEnd())
|
|
|
|
{
|
|
|
|
QString line = stream.readLine();
|
|
|
|
|
|
|
|
if (line.isEmpty() || line.startsWith("#"))
|
|
|
|
continue;
|
|
|
|
|
2024-02-29 00:01:14 +00:00
|
|
|
QRegularExpressionMatch match = replaceRe.match(line);
|
2024-02-27 01:39:49 +00:00
|
|
|
if (match.hasMatch())
|
|
|
|
{
|
|
|
|
QString key = match.captured(1).trimmed();
|
|
|
|
// Replace composing entries with a replace= line
|
2024-02-28 23:49:55 +00:00
|
|
|
if (key == QLatin1String("config") || key == QLatin1String("replace") || key == QLatin1String("data")
|
|
|
|
|| key == QLatin1String("fallback-archive") || key == QLatin1String("content")
|
|
|
|
|| key == QLatin1String("groundcover") || key == QLatin1String("script-blacklist")
|
|
|
|
|| key == QLatin1String("fallback"))
|
2024-02-27 01:39:49 +00:00
|
|
|
settings.remove(key);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
stream.seek(initialPos);
|
|
|
|
|
2013-01-26 17:19:04 +00:00
|
|
|
while (!stream.atEnd())
|
|
|
|
{
|
2013-04-25 09:04:12 +00:00
|
|
|
QString line = stream.readLine();
|
2013-01-26 17:19:04 +00:00
|
|
|
|
|
|
|
if (line.isEmpty() || line.startsWith("#"))
|
|
|
|
continue;
|
|
|
|
|
2023-01-10 18:12:13 +00:00
|
|
|
QRegularExpressionMatch match = keyRe.match(line);
|
|
|
|
if (match.hasMatch())
|
2013-01-26 17:19:04 +00:00
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
QString key = match.captured(1).trimmed();
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
SettingValue value{ match.captured(2).trimmed(), value.value, context };
|
2013-01-26 17:19:04 +00:00
|
|
|
|
2020-10-23 14:34:41 +00:00
|
|
|
// Don't remove composing entries
|
2024-02-28 23:49:55 +00:00
|
|
|
if (key != QLatin1String("config") && key != QLatin1String("replace") && key != QLatin1String("data")
|
|
|
|
&& key != QLatin1String("fallback-archive") && key != QLatin1String("content")
|
|
|
|
&& key != QLatin1String("groundcover") && key != QLatin1String("script-blacklist")
|
|
|
|
&& key != QLatin1String("fallback"))
|
2013-12-16 19:40:58 +00:00
|
|
|
settings.remove(key);
|
2020-10-23 14:34:41 +00:00
|
|
|
|
2024-02-28 23:49:55 +00:00
|
|
|
if (key == QLatin1String("config") || key == QLatin1String("user-data") || key == QLatin1String("resources")
|
|
|
|
|| key == QLatin1String("data") || key == QLatin1String("data-local")
|
2020-10-23 14:34:41 +00:00
|
|
|
|| key == QLatin1String("load-savegame"))
|
2017-10-15 00:59:21 +00:00
|
|
|
{
|
2020-10-23 14:34:41 +00:00
|
|
|
// Path line (e.g. 'data=...'), so needs processing to deal with ampersands and quotes
|
2024-02-27 01:41:12 +00:00
|
|
|
// The following is based on boost::io::detail::quoted_manip.hpp, but we don't actually use
|
|
|
|
// boost::filesystem::path anymore, and use a custom class MaybeQuotedPath which uses Boost-like quoting
|
|
|
|
// rules but internally stores as a std::filesystem::path.
|
|
|
|
// Caution: This is intentional behaviour to duplicate how Boost and what we replaced it with worked,
|
|
|
|
// and we rely on that.
|
2017-10-15 00:59:21 +00:00
|
|
|
QChar delim = '\"';
|
|
|
|
QChar escape = '&';
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
if (value.value.at(0) == delim)
|
2017-10-15 00:59:21 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QString valueOriginal = value.value;
|
|
|
|
value.value = "";
|
2017-10-15 00:59:21 +00:00
|
|
|
|
|
|
|
for (QString::const_iterator it = valueOriginal.begin() + 1; it != valueOriginal.end(); ++it)
|
|
|
|
{
|
|
|
|
if (*it == escape)
|
|
|
|
++it;
|
|
|
|
else if (*it == delim)
|
|
|
|
break;
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
value.value += *it;
|
2017-10-15 00:59:21 +00:00
|
|
|
}
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
value.originalRepresentation = value.value;
|
2017-10-15 00:59:21 +00:00
|
|
|
}
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
|
|
|
|
std::filesystem::path path = Files::pathFromQString(value.value);
|
|
|
|
mCfgMgr.processPath(path, Files::pathFromQString(context));
|
|
|
|
value.value = Files::pathToQString(path);
|
2017-10-15 00:59:21 +00:00
|
|
|
}
|
2023-03-26 18:12:20 +00:00
|
|
|
if (ignoreContent && (key == QLatin1String("content") || key == QLatin1String("data")))
|
2022-06-30 18:57:51 +00:00
|
|
|
continue;
|
2013-02-20 18:27:04 +00:00
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QList<SettingValue> values = cache.values(key);
|
2013-12-16 19:40:58 +00:00
|
|
|
values.append(settings.values(key));
|
2013-02-24 23:56:04 +00:00
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
bool exists = false;
|
|
|
|
for (const auto& existingValue : values)
|
|
|
|
{
|
|
|
|
if (existingValue.value == value.value)
|
|
|
|
{
|
|
|
|
exists = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!exists)
|
2013-02-20 18:27:04 +00:00
|
|
|
{
|
2020-06-24 10:51:26 +00:00
|
|
|
cache.insert(key, value);
|
2013-01-26 17:19:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-16 19:40:58 +00:00
|
|
|
if (settings.isEmpty())
|
|
|
|
{
|
|
|
|
settings = cache; // This is the first time we read a file
|
2013-01-26 17:19:04 +00:00
|
|
|
validatePaths();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Merge the changed keys with those which didn't
|
2013-12-16 19:40:58 +00:00
|
|
|
settings.unite(cache);
|
2013-01-26 17:19:04 +00:00
|
|
|
validatePaths();
|
2013-02-19 14:58:01 +00:00
|
|
|
|
2013-01-26 17:19:04 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-12-24 23:50:25 +00:00
|
|
|
bool Config::GameSettings::writeFile(QTextStream& stream)
|
2013-01-26 17:19:04 +00:00
|
|
|
{
|
2013-02-19 14:58:01 +00:00
|
|
|
// Iterate in reverse order to preserve insertion order
|
2023-01-15 14:33:15 +00:00
|
|
|
auto i = mUserSettings.end();
|
|
|
|
while (i != mUserSettings.begin())
|
2013-02-19 14:58:01 +00:00
|
|
|
{
|
2023-01-15 14:33:15 +00:00
|
|
|
i--;
|
2013-02-19 14:58:01 +00:00
|
|
|
|
2023-07-07 13:05:48 +00:00
|
|
|
// path lines (e.g. 'data=...') need quotes and ampersands escaping to match how boost::filesystem::path uses
|
|
|
|
// boost::io::quoted
|
|
|
|
// We don't actually use boost::filesystem::path anymore, but use a custom class MaybeQuotedPath which uses
|
|
|
|
// Boost-like quoting rules but internally stores as a std::filesystem::path.
|
|
|
|
// Caution: This is intentional behaviour to duplicate how Boost and what we replaced it with worked, and we
|
|
|
|
// rely on that.
|
2024-02-28 23:49:55 +00:00
|
|
|
if (i.key() == QLatin1String("config") || i.key() == QLatin1String("user-data")
|
|
|
|
|| i.key() == QLatin1String("resources") || i.key() == QLatin1String("data")
|
|
|
|
|| i.key() == QLatin1String("data-local") || i.key() == QLatin1String("load-savegame"))
|
2017-10-14 23:07:46 +00:00
|
|
|
{
|
|
|
|
stream << i.key() << "=";
|
|
|
|
|
2023-07-07 13:05:48 +00:00
|
|
|
// Equivalent to stream << std::quoted(i.value(), '"', '&'), which won't work on QStrings.
|
2017-10-14 23:07:46 +00:00
|
|
|
QChar delim = '\"';
|
|
|
|
QChar escape = '&';
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QString string = i.value().originalRepresentation;
|
2017-10-14 23:07:46 +00:00
|
|
|
|
|
|
|
stream << delim;
|
2022-08-15 07:52:09 +00:00
|
|
|
for (auto& it : string)
|
2017-10-14 23:07:46 +00:00
|
|
|
{
|
2020-10-22 22:03:14 +00:00
|
|
|
if (it == delim || it == escape)
|
2017-10-14 23:07:46 +00:00
|
|
|
stream << escape;
|
2020-10-22 22:03:14 +00:00
|
|
|
stream << it;
|
2017-10-14 23:07:46 +00:00
|
|
|
}
|
|
|
|
stream << delim;
|
|
|
|
|
|
|
|
stream << '\n';
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
stream << i.key() << "=" << i.value().originalRepresentation << "\n";
|
2013-02-19 14:58:01 +00:00
|
|
|
}
|
|
|
|
|
2013-10-27 19:03:12 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-10-22 22:03:14 +00:00
|
|
|
bool Config::GameSettings::isOrderedLine(const QString& line)
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
return line.contains(QRegularExpression("^\\s*fallback-archive\\s*="))
|
|
|
|
|| line.contains(QRegularExpression("^\\s*fallback\\s*="))
|
|
|
|
|| line.contains(QRegularExpression("^\\s*data\\s*="))
|
|
|
|
|| line.contains(QRegularExpression("^\\s*data-local\\s*="))
|
|
|
|
|| line.contains(QRegularExpression("^\\s*resources\\s*="))
|
|
|
|
|| line.contains(QRegularExpression("^\\s*groundcover\\s*="))
|
|
|
|
|| line.contains(QRegularExpression("^\\s*content\\s*="));
|
2015-06-14 04:51:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Policy:
|
|
|
|
//
|
|
|
|
// - Always ignore a line beginning with '#' or empty lines; added above a config
|
|
|
|
// entry.
|
|
|
|
//
|
|
|
|
// - If a line in file exists with matching key and first part of value (before ',',
|
|
|
|
// '\n', etc) also matches, then replace the line with that of mUserSettings.
|
|
|
|
// - else remove line
|
|
|
|
//
|
|
|
|
// - If there is no corresponding line in file, add at the end
|
|
|
|
//
|
2015-06-14 23:53:26 +00:00
|
|
|
// - Removed content items are saved as comments if the item had any comments.
|
|
|
|
// Content items prepended with '##' are considered previously removed.
|
|
|
|
//
|
2015-06-14 04:51:01 +00:00
|
|
|
bool Config::GameSettings::writeFileWithComments(QFile& file)
|
|
|
|
{
|
|
|
|
QTextStream stream(&file);
|
2023-01-12 21:29:48 +00:00
|
|
|
Misc::ensureUtf8Encoding(stream);
|
2015-06-14 04:51:01 +00:00
|
|
|
|
|
|
|
// slurp
|
|
|
|
std::vector<QString> fileCopy;
|
|
|
|
QString line = stream.readLine();
|
|
|
|
while (!line.isNull())
|
|
|
|
{
|
|
|
|
fileCopy.push_back(line);
|
|
|
|
line = stream.readLine();
|
|
|
|
}
|
|
|
|
stream.seek(0);
|
|
|
|
|
|
|
|
// empty file, no comments to keep
|
|
|
|
if (fileCopy.empty())
|
|
|
|
return writeFile(stream);
|
|
|
|
|
|
|
|
// start
|
|
|
|
// |
|
|
|
|
// | +----------------------------------------------------------+
|
|
|
|
// | | |
|
|
|
|
// v v |
|
|
|
|
// skip non-"ordered" lines (remove "ordered" lines) |
|
|
|
|
// | ^ |
|
|
|
|
// | | |
|
|
|
|
// | non-"ordered" line, write saved comments |
|
|
|
|
// | ^ |
|
|
|
|
// v | |
|
|
|
|
// blank or comment line, save in temp buffer <--------+ |
|
|
|
|
// | | | |
|
2015-06-14 23:53:26 +00:00
|
|
|
// | +------- comment line ------+ |
|
|
|
|
// v (special processing '##') |
|
2015-06-14 04:51:01 +00:00
|
|
|
// "ordered" line |
|
|
|
|
// | |
|
|
|
|
// v |
|
|
|
|
// save in a separate map of comments keyed by "ordered" line |
|
|
|
|
// | |
|
|
|
|
// +----------------------------------------------------------+
|
|
|
|
//
|
|
|
|
//
|
2023-01-10 18:12:13 +00:00
|
|
|
QRegularExpression settingRegex("^([^=]+)\\s*=\\s*([^,]+)(.*)$");
|
2015-06-14 04:51:01 +00:00
|
|
|
std::vector<QString> comments;
|
2020-10-22 22:03:14 +00:00
|
|
|
auto commentStart = fileCopy.end();
|
2015-06-14 04:51:01 +00:00
|
|
|
std::map<QString, std::vector<QString>> commentsMap;
|
2020-10-22 22:03:14 +00:00
|
|
|
for (auto iter = fileCopy.begin(); iter != fileCopy.end(); ++iter)
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
|
|
|
if (isOrderedLine(*iter))
|
|
|
|
{
|
|
|
|
// save in a separate map of comments keyed by "ordered" line
|
|
|
|
if (!comments.empty())
|
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
QRegularExpressionMatch match = settingRegex.match(*iter);
|
|
|
|
if (match.hasMatch())
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
commentsMap[match.captured(1) + "=" + match.captured(2)] = comments;
|
2015-06-14 04:51:01 +00:00
|
|
|
comments.clear();
|
|
|
|
commentStart = fileCopy.end();
|
|
|
|
}
|
|
|
|
// else do nothing, malformed line
|
|
|
|
}
|
|
|
|
|
|
|
|
*iter = QString(); // "ordered" lines to be removed later
|
|
|
|
}
|
2023-01-10 18:12:13 +00:00
|
|
|
else if ((*iter).isEmpty() || (*iter).contains(QRegularExpression("^\\s*#")))
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
|
|
|
// comment line, save in temp buffer
|
|
|
|
if (comments.empty())
|
|
|
|
commentStart = iter;
|
2015-06-14 23:53:26 +00:00
|
|
|
|
|
|
|
// special removed content processing
|
2023-01-10 18:12:13 +00:00
|
|
|
if ((*iter).contains(QRegularExpression("^##content\\s*=")))
|
2015-06-14 23:53:26 +00:00
|
|
|
{
|
|
|
|
if (!comments.empty())
|
|
|
|
{
|
|
|
|
commentsMap[*iter] = comments;
|
|
|
|
comments.clear();
|
|
|
|
commentStart = fileCopy.end();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
comments.push_back(*iter);
|
|
|
|
|
2015-06-14 04:51:01 +00:00
|
|
|
*iter = QString(); // assume to be deleted later
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
QRegularExpressionMatch match = settingRegex.match(*iter);
|
2015-06-14 04:51:01 +00:00
|
|
|
|
|
|
|
// blank or non-"ordered" line, write saved comments
|
2023-01-10 18:12:13 +00:00
|
|
|
if (!comments.empty() && match.hasMatch() && settingRegex.captureCount() >= 2
|
|
|
|
&& mUserSettings.find(match.captured(1)) != mUserSettings.end())
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2018-11-15 06:21:08 +00:00
|
|
|
if (commentStart == fileCopy.end())
|
|
|
|
throw std::runtime_error(
|
|
|
|
"Config::GameSettings: failed to parse settings - iterator is past of end of settings file");
|
|
|
|
|
2020-10-22 22:03:14 +00:00
|
|
|
for (const auto& comment : comments)
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2020-10-22 22:03:14 +00:00
|
|
|
*commentStart = comment;
|
2015-06-14 04:51:01 +00:00
|
|
|
++commentStart;
|
|
|
|
}
|
|
|
|
comments.clear();
|
|
|
|
commentStart = fileCopy.end();
|
|
|
|
}
|
|
|
|
|
|
|
|
// keep blank lines and non-"ordered" lines other than comments
|
|
|
|
|
|
|
|
// look for a key in the line
|
2023-01-10 18:12:13 +00:00
|
|
|
if (!match.hasMatch() || settingRegex.captureCount() < 2)
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
|
|
|
// no key or first part of value found in line, replace with a null string which
|
2023-01-10 18:12:13 +00:00
|
|
|
// will be removed later
|
2015-06-14 04:51:01 +00:00
|
|
|
*iter = QString();
|
|
|
|
comments.clear();
|
|
|
|
commentStart = fileCopy.end();
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// look for a matching key in user settings
|
|
|
|
*iter = QString(); // assume no match
|
2023-01-10 18:12:13 +00:00
|
|
|
QString key = match.captured(1);
|
|
|
|
QString keyVal = match.captured(1) + "=" + match.captured(2);
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QMultiMap<QString, SettingValue>::const_iterator i = mUserSettings.find(key);
|
2015-06-14 04:51:01 +00:00
|
|
|
while (i != mUserSettings.end() && i.key() == key)
|
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
// todo: does this need to handle paths?
|
|
|
|
QString settingLine = i.key() + "=" + i.value().originalRepresentation;
|
2023-01-10 18:12:13 +00:00
|
|
|
QRegularExpressionMatch keyMatch = settingRegex.match(settingLine);
|
|
|
|
if (keyMatch.hasMatch())
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
if ((keyMatch.captured(1) + "=" + keyMatch.captured(2)) == keyVal)
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2024-01-19 12:01:48 +00:00
|
|
|
*iter = std::move(settingLine);
|
2015-06-14 04:51:01 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
++i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// comments at top of file
|
2020-10-22 22:03:14 +00:00
|
|
|
for (auto& iter : fileCopy)
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2020-10-22 22:03:14 +00:00
|
|
|
if (iter.isNull())
|
2015-06-14 04:51:01 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// Below is based on readFile() code, if that changes corresponding change may be
|
|
|
|
// required (for example duplicates may be inserted if the rules don't match)
|
2023-01-10 18:12:13 +00:00
|
|
|
if (/*(*iter).isEmpty() ||*/ iter.contains(QRegularExpression("^\\s*#")))
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2020-10-22 22:03:14 +00:00
|
|
|
stream << iter << "\n";
|
2015-06-14 04:51:01 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Iterate in reverse order to preserve insertion order
|
|
|
|
QString settingLine;
|
2023-01-15 14:33:15 +00:00
|
|
|
auto it = mUserSettings.end();
|
|
|
|
while (it != mUserSettings.begin())
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2023-01-15 14:33:15 +00:00
|
|
|
it--;
|
2015-06-14 04:51:01 +00:00
|
|
|
|
2023-07-07 13:05:48 +00:00
|
|
|
// path lines (e.g. 'data=...') need quotes and ampersands escaping to match how boost::filesystem::path uses
|
|
|
|
// boost::io::quoted
|
|
|
|
// We don't actually use boost::filesystem::path anymore, but use a custom class MaybeQuotedPath which uses
|
|
|
|
// Boost-like quoting rules but internally stores as a std::filesystem::path.
|
|
|
|
// Caution: This is intentional behaviour to duplicate how Boost and what we replaced it with worked, and we
|
|
|
|
// rely on that.
|
2024-02-28 23:49:55 +00:00
|
|
|
if (it.key() == QLatin1String("config") || it.key() == QLatin1String("user-data")
|
|
|
|
|| it.key() == QLatin1String("resources") || it.key() == QLatin1String("data")
|
|
|
|
|| it.key() == QLatin1String("data-local") || it.key() == QLatin1String("load-savegame"))
|
2017-10-15 00:59:21 +00:00
|
|
|
{
|
|
|
|
settingLine = it.key() + "=";
|
|
|
|
|
2023-07-07 13:05:48 +00:00
|
|
|
// Equivalent to settingLine += std::quoted(it.value(), '"', '&'), which won't work on QStrings.
|
2017-10-15 00:59:21 +00:00
|
|
|
QChar delim = '\"';
|
|
|
|
QChar escape = '&';
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QString string = it.value().originalRepresentation;
|
2017-10-15 00:59:21 +00:00
|
|
|
|
|
|
|
settingLine += delim;
|
2022-08-15 07:52:09 +00:00
|
|
|
for (auto& iter : string)
|
2017-10-15 00:59:21 +00:00
|
|
|
{
|
2020-10-22 22:03:14 +00:00
|
|
|
if (iter == delim || iter == escape)
|
2017-10-15 00:59:21 +00:00
|
|
|
settingLine += escape;
|
2020-10-22 22:03:14 +00:00
|
|
|
settingLine += iter;
|
2017-10-15 00:59:21 +00:00
|
|
|
}
|
|
|
|
settingLine += delim;
|
|
|
|
}
|
2015-06-14 04:51:01 +00:00
|
|
|
else
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
settingLine = it.key() + "=" + it.value().originalRepresentation;
|
2015-06-14 04:51:01 +00:00
|
|
|
|
2023-01-10 18:12:13 +00:00
|
|
|
QRegularExpressionMatch match = settingRegex.match(settingLine);
|
|
|
|
if (match.hasMatch())
|
2015-06-14 04:51:01 +00:00
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
auto i = commentsMap.find(match.captured(1) + "=" + match.captured(2));
|
2015-06-14 04:51:01 +00:00
|
|
|
|
2015-06-14 23:53:26 +00:00
|
|
|
// check if previous removed content item with comments
|
|
|
|
if (i == commentsMap.end())
|
2023-01-10 18:12:13 +00:00
|
|
|
i = commentsMap.find("##" + match.captured(1) + "=" + match.captured(2));
|
2015-06-14 23:53:26 +00:00
|
|
|
|
2015-06-14 04:51:01 +00:00
|
|
|
if (i != commentsMap.end())
|
|
|
|
{
|
|
|
|
std::vector<QString> cLines = i->second;
|
2020-10-22 22:03:14 +00:00
|
|
|
for (const auto& cLine : cLines)
|
|
|
|
stream << cLine << "\n";
|
2015-06-14 23:53:26 +00:00
|
|
|
|
|
|
|
commentsMap.erase(i);
|
2015-06-14 04:51:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
stream << settingLine << "\n";
|
|
|
|
}
|
|
|
|
|
2015-06-14 23:53:26 +00:00
|
|
|
// flush any removed settings
|
|
|
|
if (!commentsMap.empty())
|
|
|
|
{
|
2020-10-22 22:03:14 +00:00
|
|
|
auto i = commentsMap.begin();
|
2015-06-14 23:53:26 +00:00
|
|
|
for (; i != commentsMap.end(); ++i)
|
|
|
|
{
|
2023-01-10 18:12:13 +00:00
|
|
|
if (i->first.contains(QRegularExpression("^\\s*content\\s*=")))
|
2015-06-14 23:53:26 +00:00
|
|
|
{
|
|
|
|
std::vector<QString> cLines = i->second;
|
2020-10-22 22:03:14 +00:00
|
|
|
for (const auto& cLine : cLines)
|
|
|
|
stream << cLine << "\n";
|
2015-06-14 23:53:26 +00:00
|
|
|
|
|
|
|
// mark the content line entry for future preocessing
|
|
|
|
stream << "##" << i->first << "\n";
|
|
|
|
|
|
|
|
// commentsMap.erase(i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-14 04:51:01 +00:00
|
|
|
// flush any end comments
|
|
|
|
if (!comments.empty())
|
|
|
|
{
|
2020-10-22 22:03:14 +00:00
|
|
|
for (const auto& comment : comments)
|
|
|
|
stream << comment << "\n";
|
2015-06-14 04:51:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
file.resize(file.pos());
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-12-24 23:50:25 +00:00
|
|
|
bool Config::GameSettings::hasMaster()
|
2013-10-27 19:03:12 +00:00
|
|
|
{
|
2013-12-16 19:40:58 +00:00
|
|
|
bool result = false;
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QList<SettingValue> content = mSettings.values(QString(Config::GameSettings::sContentKey));
|
2018-03-28 12:43:51 +00:00
|
|
|
for (int i = 0; i < content.count(); ++i)
|
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
if (content.at(i).value.endsWith(QLatin1String(".omwgame"), Qt::CaseInsensitive)
|
|
|
|
|| content.at(i).value.endsWith(QLatin1String(".esm"), Qt::CaseInsensitive))
|
2018-03-28 12:43:51 +00:00
|
|
|
{
|
2013-12-16 19:40:58 +00:00
|
|
|
result = true;
|
|
|
|
break;
|
|
|
|
}
|
2013-01-25 04:19:06 +00:00
|
|
|
}
|
2013-02-18 16:59:08 +00:00
|
|
|
|
2013-12-16 19:40:58 +00:00
|
|
|
return result;
|
2013-01-25 04:19:06 +00:00
|
|
|
}
|
2015-01-10 05:46:47 +00:00
|
|
|
|
2020-04-26 13:31:39 +00:00
|
|
|
void Config::GameSettings::setContentList(
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
const QList<SettingValue>& dirNames, const QList<SettingValue>& archiveNames, const QStringList& fileNames)
|
2015-01-10 05:46:47 +00:00
|
|
|
{
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
remove(sDirectoryKey);
|
|
|
|
for (auto const& item : dirNames)
|
|
|
|
setMultiValue(sDirectoryKey, item);
|
|
|
|
remove(sArchiveKey);
|
|
|
|
for (auto const& item : archiveNames)
|
|
|
|
setMultiValue(sArchiveKey, item);
|
2024-03-06 23:52:16 +00:00
|
|
|
remove(sContentKey);
|
|
|
|
for (auto const& item : fileNames)
|
|
|
|
setMultiValue(sContentKey, { item });
|
2020-04-26 13:31:39 +00:00
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QList<Config::SettingValue> Config::GameSettings::getDataDirs() const
|
2020-04-26 13:31:39 +00:00
|
|
|
{
|
2023-01-08 18:02:03 +00:00
|
|
|
return reverse(mDataDirs);
|
2020-04-26 13:31:39 +00:00
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QList<Config::SettingValue> Config::GameSettings::getArchiveList() const
|
2020-04-26 13:31:39 +00:00
|
|
|
{
|
|
|
|
// QMap returns multiple rows in LIFO order, so need to reverse
|
2023-01-08 18:02:03 +00:00
|
|
|
return reverse(values(sArchiveKey));
|
2015-01-10 05:46:47 +00:00
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
QList<Config::SettingValue> Config::GameSettings::getContentList() const
|
2015-01-10 05:46:47 +00:00
|
|
|
{
|
|
|
|
// QMap returns multiple rows in LIFO order, so need to reverse
|
2023-01-08 18:02:03 +00:00
|
|
|
return reverse(values(sContentKey));
|
2015-01-10 05:46:47 +00:00
|
|
|
}
|
|
|
|
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
bool Config::GameSettings::isUserSetting(const SettingValue& settingValue) const
|
|
|
|
{
|
|
|
|
return settingValue.context.isEmpty() || settingValue.context == getUserContext();
|
|
|
|
}
|
|
|
|
|
2015-11-27 19:52:29 +00:00
|
|
|
void Config::GameSettings::clear()
|
|
|
|
{
|
|
|
|
mSettings.clear();
|
Track source of settings
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
2024-03-06 00:36:13 +00:00
|
|
|
mContexts.clear();
|
2015-11-27 19:52:29 +00:00
|
|
|
mUserSettings.clear();
|
|
|
|
mDataDirs.clear();
|
|
|
|
mDataLocal.clear();
|
|
|
|
}
|
2024-03-31 23:15:58 +00:00
|
|
|
|
|
|
|
QDataStream& Config::operator<<(QDataStream& out, const SettingValue& settingValue)
|
|
|
|
{
|
|
|
|
out << settingValue.value;
|
|
|
|
out << settingValue.originalRepresentation;
|
|
|
|
out << settingValue.context;
|
|
|
|
return out;
|
|
|
|
}
|
|
|
|
|
|
|
|
QDataStream& Config::operator>>(QDataStream& in, SettingValue& settingValue)
|
|
|
|
{
|
|
|
|
in >> settingValue.value;
|
|
|
|
in >> settingValue.originalRepresentation;
|
|
|
|
in >> settingValue.context;
|
|
|
|
return in;
|
|
|
|
}
|