|
|
|
#include "importpage.hpp"
|
|
|
|
|
|
|
|
#include <QDebug>
|
|
|
|
#include <QDir>
|
|
|
|
#include <QFileDialog>
|
|
|
|
#include <QMessageBox>
|
|
|
|
|
|
|
|
#include <components/files/configurationmanager.hpp>
|
|
|
|
#include <components/files/qtconversion.hpp>
|
|
|
|
|
|
|
|
using namespace Process;
|
|
|
|
|
|
|
|
Launcher::ImportPage::ImportPage(const Files::ConfigurationManager& cfg, Config::GameSettings& gameSettings,
|
|
|
|
Config::LauncherSettings& launcherSettings, MainDialog* parent)
|
|
|
|
: QWidget(parent)
|
|
|
|
, mCfgMgr(cfg)
|
|
|
|
, mGameSettings(gameSettings)
|
|
|
|
, mLauncherSettings(launcherSettings)
|
|
|
|
, mMain(parent)
|
|
|
|
{
|
|
|
|
setupUi(this);
|
|
|
|
|
|
|
|
mWizardInvoker = new ProcessInvoker();
|
|
|
|
mImporterInvoker = new ProcessInvoker();
|
|
|
|
resetProgressBar();
|
|
|
|
|
|
|
|
connect(mWizardInvoker->getProcess(), &QProcess::started, this, &ImportPage::wizardStarted);
|
|
|
|
|
|
|
|
connect(mWizardInvoker->getProcess(), qOverload<int, QProcess::ExitStatus>(&QProcess::finished), this,
|
|
|
|
&ImportPage::wizardFinished);
|
|
|
|
|
|
|
|
connect(mImporterInvoker->getProcess(), &QProcess::started, this, &ImportPage::importerStarted);
|
|
|
|
|
|
|
|
connect(mImporterInvoker->getProcess(), qOverload<int, QProcess::ExitStatus>(&QProcess::finished), this,
|
|
|
|
&ImportPage::importerFinished);
|
|
|
|
|
|
|
|
// Detect Morrowind configuration files
|
|
|
|
QStringList iniPaths;
|
|
|
|
|
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.
10 months ago
|
|
|
for (const auto& path : mGameSettings.getDataDirs())
|
|
|
|
{
|
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.
10 months ago
|
|
|
QDir dir(path.value);
|
|
|
|
dir.setPath(dir.canonicalPath()); // Resolve symlinks
|
|
|
|
|
|
|
|
if (dir.exists(QString("Morrowind.ini")))
|
|
|
|
iniPaths.append(dir.absoluteFilePath(QString("Morrowind.ini")));
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!dir.cdUp())
|
|
|
|
continue; // Cannot move from Data Files
|
|
|
|
|
|
|
|
if (dir.exists(QString("Morrowind.ini")))
|
|
|
|
iniPaths.append(dir.absoluteFilePath(QString("Morrowind.ini")));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!iniPaths.isEmpty())
|
|
|
|
{
|
|
|
|
settingsComboBox->addItems(iniPaths);
|
|
|
|
importerButton->setEnabled(true);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
importerButton->setEnabled(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
loadSettings();
|
|
|
|
}
|
|
|
|
|
|
|
|
Launcher::ImportPage::~ImportPage()
|
|
|
|
{
|
|
|
|
delete mWizardInvoker;
|
|
|
|
delete mImporterInvoker;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::on_wizardButton_clicked()
|
|
|
|
{
|
|
|
|
mMain->writeSettings();
|
|
|
|
|
|
|
|
if (!mWizardInvoker->startProcess(QLatin1String("openmw-wizard"), false))
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::on_importerButton_clicked()
|
|
|
|
{
|
|
|
|
mMain->writeSettings();
|
|
|
|
|
|
|
|
// Create the file if it doesn't already exist, else the importer will fail
|
|
|
|
auto path = mCfgMgr.getUserConfigPath();
|
|
|
|
path /= "openmw.cfg";
|
|
|
|
#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
|
|
|
|
QFile file(path);
|
|
|
|
#else
|
|
|
|
QFile file(Files::pathToQString(path));
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (!file.exists())
|
|
|
|
{
|
|
|
|
if (!file.open(QIODevice::ReadWrite))
|
|
|
|
{
|
|
|
|
// File cannot be created
|
|
|
|
QMessageBox msgBox;
|
|
|
|
msgBox.setWindowTitle(tr("Error writing OpenMW configuration file"));
|
|
|
|
msgBox.setIcon(QMessageBox::Critical);
|
|
|
|
msgBox.setStandardButtons(QMessageBox::Ok);
|
|
|
|
msgBox.setText(
|
|
|
|
tr("<html><head/><body><p><b>Could not open or create %1 for writing </b></p>"
|
|
|
|
"<p>Please make sure you have the right permissions "
|
|
|
|
"and try again.</p></body></html>")
|
|
|
|
.arg(file.fileName()));
|
|
|
|
msgBox.exec();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
file.close();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Construct the arguments to run the importer
|
|
|
|
QStringList arguments;
|
|
|
|
|
|
|
|
if (addonsCheckBox->isChecked())
|
|
|
|
arguments.append(QString("--game-files"));
|
|
|
|
|
|
|
|
if (fontsCheckBox->isChecked())
|
|
|
|
arguments.append(QString("--fonts"));
|
|
|
|
|
|
|
|
arguments.append(QString("--encoding"));
|
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.
10 months ago
|
|
|
arguments.append(mGameSettings.value(QString("encoding"), { "win1252" }).value);
|
|
|
|
arguments.append(QString("--ini"));
|
|
|
|
arguments.append(settingsComboBox->currentText());
|
|
|
|
arguments.append(QString("--cfg"));
|
|
|
|
arguments.append(Files::pathToQString(path));
|
|
|
|
|
|
|
|
qDebug() << "arguments " << arguments;
|
|
|
|
|
|
|
|
// start the progress bar as a "bouncing ball"
|
|
|
|
progressBar->setMaximum(0);
|
|
|
|
progressBar->setValue(0);
|
|
|
|
if (!mImporterInvoker->startProcess(QLatin1String("openmw-iniimporter"), arguments, false))
|
|
|
|
{
|
|
|
|
resetProgressBar();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::on_browseButton_clicked()
|
|
|
|
{
|
|
|
|
QString iniFile = QFileDialog::getOpenFileName(this, QObject::tr("Select configuration file"), QDir::currentPath(),
|
|
|
|
QString(tr("Morrowind configuration file (*.ini)")));
|
|
|
|
|
|
|
|
if (iniFile.isEmpty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
QFileInfo info(iniFile);
|
|
|
|
|
|
|
|
if (!info.exists() || !info.isReadable())
|
|
|
|
return;
|
|
|
|
|
|
|
|
const QString path(QDir::toNativeSeparators(info.absoluteFilePath()));
|
|
|
|
|
|
|
|
if (settingsComboBox->findText(path) == -1)
|
|
|
|
{
|
|
|
|
settingsComboBox->addItem(path);
|
|
|
|
settingsComboBox->setCurrentIndex(settingsComboBox->findText(path));
|
|
|
|
importerButton->setEnabled(true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::wizardStarted()
|
|
|
|
{
|
|
|
|
mMain->hide(); // Hide the launcher
|
|
|
|
|
|
|
|
wizardButton->setEnabled(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::wizardFinished(int exitCode, QProcess::ExitStatus exitStatus)
|
|
|
|
{
|
|
|
|
if (exitCode != 0 || exitStatus == QProcess::CrashExit)
|
|
|
|
return qApp->quit();
|
|
|
|
|
|
|
|
mMain->reloadSettings();
|
|
|
|
wizardButton->setEnabled(true);
|
|
|
|
|
|
|
|
mMain->show(); // Show the launcher again
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::importerStarted()
|
|
|
|
{
|
|
|
|
importerButton->setEnabled(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::importerFinished(int exitCode, QProcess::ExitStatus exitStatus)
|
|
|
|
{
|
|
|
|
if (exitCode != 0 || exitStatus == QProcess::CrashExit)
|
|
|
|
{
|
|
|
|
resetProgressBar();
|
|
|
|
|
|
|
|
QMessageBox msgBox;
|
|
|
|
msgBox.setWindowTitle(tr("Importer finished"));
|
|
|
|
msgBox.setStandardButtons(QMessageBox::Ok);
|
|
|
|
msgBox.setIcon(QMessageBox::Warning);
|
|
|
|
msgBox.setText(tr("Failed to import settings from INI file."));
|
|
|
|
msgBox.exec();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// indicate progress finished
|
|
|
|
progressBar->setMaximum(1);
|
|
|
|
progressBar->setValue(1);
|
|
|
|
|
|
|
|
// Importer may have changed settings, so refresh
|
|
|
|
mMain->reloadSettings();
|
|
|
|
}
|
|
|
|
|
|
|
|
importerButton->setEnabled(true);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::resetProgressBar()
|
|
|
|
{
|
|
|
|
// set progress bar to 0 %
|
|
|
|
progressBar->reset();
|
|
|
|
}
|
|
|
|
|
|
|
|
void Launcher::ImportPage::saveSettings() {}
|
|
|
|
|
|
|
|
bool Launcher::ImportPage::loadSettings()
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|