You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
openmw/apps/launcher/datafilespage.hpp

159 lines
4.9 KiB
C++

#ifndef DATAFILESPAGE_H
#define DATAFILESPAGE_H
#include "ui_datafilespage.h"
#include <components/process/processinvoker.hpp>
#include <QDir>
#include <QMenu>
#include <QStringList>
#include <QWidget>
class QSortFilterProxyModel;
class QAbstractItemModel;
class QMenu;
namespace Files
{
struct ConfigurationManager;
}
namespace ContentSelectorView
{
class ContentSelector;
}
namespace Config
{
class GameSettings;
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
struct SettingValue;
class LauncherSettings;
}
namespace Launcher
{
class MainDialog;
class TextInputDialog;
class ProfilesComboBox;
class DataFilesPage : public QWidget
{
Q_OBJECT
ContentSelectorView::ContentSelector* mSelector;
Ui::DataFilesPage ui;
QMenu* mArchiveContextMenu;
QMenu* mDataFilesContextMenu;
public:
explicit DataFilesPage(const Files::ConfigurationManager& cfg, Config::GameSettings& gameSettings,
Config::LauncherSettings& launcherSettings, MainDialog* parent = nullptr);
QAbstractItemModel* profilesModel() const;
int profilesIndex() const;
// void writeConfig(QString profile = QString());
void saveSettings(const QString& profile = "");
bool loadSettings();
signals:
void signalProfileChanged(int index);
void signalLoadedCellsChanged(QStringList selectedFiles);
public slots:
void slotProfileChanged(int index);
private slots:
void slotProfileChangedByUser(const QString& previous, const QString& current);
void slotProfileRenamed(const QString& previous, const QString& current);
void slotProfileDeleted(const QString& item);
void slotAddonDataChanged();
void slotRefreshButtonClicked();
void updateNewProfileOkButton(const QString& text);
void updateCloneProfileOkButton(const QString& text);
void addSubdirectories(bool append);
void sortDirectories();
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
void sortArchives();
void removeDirectory();
void moveSources(QListWidget* sourceList, int step);
void slotShowArchiveContextMenu(const QPoint& pos);
void slotShowDataFilesContextMenu(const QPoint& pos);
void slotCheckMultiSelectedItems();
void slotUncheckMultiSelectedItems();
void on_newProfileAction_triggered();
void on_cloneProfileAction_triggered();
void on_deleteProfileAction_triggered();
void startNavMeshTool();
void killNavMeshTool();
void readNavMeshToolStdout();
void readNavMeshToolStderr();
void navMeshToolFinished(int exitCode, QProcess::ExitStatus exitStatus);
public:
/// Content List that is always present
const static char* mDefaultContentListName;
private:
struct NavMeshToolProgress
{
bool mEnabled = true;
QByteArray mLogData;
QByteArray mMessagesData;
std::map<std::uint64_t, std::string> mWorldspaces;
int mCellsCount = 0;
int mExpectedMaxProgress = 0;
};
MainDialog* mMainDialog;
TextInputDialog* mNewProfileDialog;
TextInputDialog* mCloneProfileDialog;
const Files::ConfigurationManager& mCfgMgr;
Config::GameSettings& mGameSettings;
Config::LauncherSettings& mLauncherSettings;
QString mPreviousProfile;
QStringList previousSelectedFiles;
QString mDataLocal;
QStringList mKnownArchives;
QStringList mNewDataDirs;
Process::ProcessInvoker* mNavMeshToolInvoker;
NavMeshToolProgress mNavMeshToolProgress;
void addArchive(const QString& name, Qt::CheckState selected, int row = -1);
void addArchivesFromDir(const QString& dir);
void buildView();
void buildArchiveContextMenu();
void buildDataFilesContextMenu();
void setCheckStateForMultiSelectedItems(bool checked);
void setProfile(int index, bool savePrevious);
void setProfile(const QString& previous, const QString& current, bool savePrevious);
void removeProfile(const QString& profile);
bool showDeleteMessageBox(const QString& text);
void addProfile(const QString& profile, bool setAsCurrent);
void checkForDefaultProfile();
void populateFileViews(const QString& contentModelName);
void reloadCells(QStringList selectedFiles);
void refreshDataFilesView();
void updateNavMeshProgress(int minDataSize);
void slotCopySelectedItemsPaths();
void slotOpenSelectedItemsPaths();
/**
* Returns the file paths of all selected content files
* @return the file paths of all selected content files
*/
QStringList selectedFilePaths() const;
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
QList<Config::SettingValue> selectedArchivePaths() const;
QList<Config::SettingValue> selectedDirectoriesPaths() const;
};
}
#endif