Static Public Member Functions
|static void||debug ()|
|static QStringList||entryList (const QString &relativePath, QDir::Filters filters=QDir::NoFilter)|
|static QString||localPath ()|
|static QString||marbleDataPath ()|
|static QString||marblePluginPath ()|
|static QStringList||oldLocalPaths ()|
|static QString||path (const QString &relativePath)|
|static QStringList||pluginEntryList (const QString &relativePath, QDir::Filters filters=QDir::NoFilter)|
|static QString||pluginLocalPath ()|
|static QString||pluginPath (const QString &relativePath)|
|static QString||pluginSystemPath ()|
|static void||setMarbleDataPath (const QString &adaptedPath)|
|static void||setMarblePluginPath (const QString &adaptedPath)|
|static QString||systemPath ()|
A class that manages data look-up for Marble.
The class basically does for Marble what KStandardDirs did for KDE4. Given that the MarbleWidget is a Qt5-only library and given that it comes with its own model and data we need this class.
The class needs to respect the requirements of the different plattforms, so to avoid very different implementations for each plattform we specify how data should get looked up:
Generally there are two places of which Marble will draw it's data from:
"localPath" and "systemPath".
look-up of the data should happen in the localPath first. Only if the look-up in the localPath failed then MarbleDirs should look up the data in the systemPath.
localPath: The place for localPath should match space that is fully accessible to the user. On Unix-like plattforms this matches QDir::homePath() + "/.marble/data"
systemPath: Ideally the systemPath should match the place where cmake installed the data for marble. However this doesn't work for all plattforms:
- For Linux and Mac non-bundle deployment the location can be chosen using the cmake MARBLE_DATA_PATH option at compile time.
- For Mac bundle deployment the location inside the bundle gets chosen as the default location.
- For Windows a path relative to the application binary can be chosen as this should usually work without problems.
To allow kiosk-like setups and for custom setups in general it should be possible to change the place of the systemPath at runtime. Therefore we introduce a global variable "MarbleDataPath" in the MarbleDirs.h source code. Initially MarbleDataPath is empty. The systemPath will point to MarbleDataPath as soon as it gets changed to a valid non-empty path. So as soon as MarbleDataPath contains a valid path the path specified by cmake will get ignored.
( Possible future extension: if the MarbleDataPath contains several valid paths separated by a colon then each of these paths should be used for look up in the same order as for the KDE kiosk framework. )
It's the duty of each application that uses the MarbleWidget to retrieve the value of the MarbleDataPath from the MarbleWidget and to save it in its settings and restore it on start-up of the application.
Definition at line 74 of file MarbleDirs.h.
The documentation for this class was generated from the following files:
Documentation copyright © 1996-2023 The KDE developers.
Generated on Mon Mar 27 2023 04:23:32 by doxygen 1.8.17 written by Dimitri van Heesch, © 1997-2006
KDE's Doxygen guidelines are available online.