Re: [SailfishDevel] Sharing a common OfflineStorage DB between multiple Sailfish apps.
Hi,
What are the pros and cons of using QStandardPaths as opposed to XDG
Environmental Variables?
If you look into the unix implementation of the class QStandardPaths, you find
something like
QString QStandardPaths::writableLocation(StandardLocation type)
{
switch (type) {
case HomeLocation:
return QDir::homePath();
case TempLocation:
return QDir::tempPath();
case CacheLocation:
case GenericCacheLocation:
{
// http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
QString xdgCacheHome = QFile::decodeName(qgetenv(XDG_CACHE_HOME));
if (isTestModeEnabled())
xdgCacheHome = QDir::homePath() + QLatin1String(/.qttest/cache);
if (xdgCacheHome.isEmpty())
xdgCacheHome = QDir::homePath() + QLatin1String(/.cache);
if (type == QStandardPaths::CacheLocation)
appendOrganizationAndApp(xdgCacheHome);
return xdgCacheHome;
}
case DataLocation:
case GenericDataLocation:
{
QString xdgDataHome = QFile::decodeName(qgetenv(XDG_DATA_HOME));
if (isTestModeEnabled())
xdgDataHome = QDir::homePath() + QLatin1String(/.qttest/share);
if (xdgDataHome.isEmpty())
xdgDataHome = QDir::homePath() + QLatin1String(/.local/share);
if (type == QStandardPaths::DataLocation)
appendOrganizationAndApp(xdgDataHome);
return xdgDataHome;
}
case ConfigLocation:
{
// http://standards.freedesktop.org/basedir-spec/latest/
QString xdgConfigHome = QFile::decodeName(qgetenv(XDG_CONFIG_HOME));
if (isTestModeEnabled())
xdgConfigHome = QDir::homePath() + QLatin1String(/.qttest/config);
if (xdgConfigHome.isEmpty())
xdgConfigHome = QDir::homePath() + QLatin1String(/.config);
return xdgConfigHome;
}
So using QStandardPaths is
* convenience and brings you
* OS independance, because they (Qt) tend to choose the right position.
BR.
Sven
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
SailfishOS.org Devel mailing list
Re: [SailfishDevel] Sharing a common OfflineStorage DB between multiple Sailfish apps.
Hi, On 16 Jan 2014, at 13:14, christopher.l...@thurweb.ch wrote: This gives the following Application Output: [D] main:42 - offlineStoragPath orig: /home/nemo/.local/share/CreateDBQt5/QML/OfflineStorage [D] main:44 - offlineStoragPath new: /home/nemo/.local/share/landed25_QT5/QML/OfflineStorage The database is indeed created in /home/nemo/.local/share/landed25_QT5/QML/OfflineStorage, and is accessible to the app landed25_QT5 Note the order of the view-engine()-setOfflineStoragePath... and view-setSource... calls is crucial. If the setSource comes first, then the QML is initiated before the storagePath is changed! In my next experiment I will try to change the storageLocation to something like QStandardPaths::GenericDataLocation. The question on harbour acceptability remains ... For Harbour, using QStandardPaths should always be safe, but append the name of your application (harbour-myapp) to the path, so that all your application-specific data ends up there. Note that there is (in line with XDG) the data directory (where you store data, e.g. documents or something), the config directory (where you store configuration options, e.g. enabled/disabled states of features) and the cache directory (where you store data that can be safely deleted in case of low disk uage - e.g. user avatars from a web service or previews/thumbnails of documents, etc… - everything that can be re-created easily). This is important, as this can be used in the future from a system service to calculate per-app disk usage and allow clearing of application data, integration with backup, etc… - also, it’s easier for power users to SSH into the device and find where their user data is. If you use QStandardPaths or XDG, you can be sure that if (when) the data location changes in the future, your application will still work correctly. Absolute no-no: Hardcoding “/home/nemo/“ (if you need to find the user’s home directory, get the environment variable $HOME instead) and hardcoding the default values for the XDG data directories without looking up the environment variables ($XDG_DATA_HOME, $XDG_CONFIG_HOME, $XDG_CACHE_HOME) instead. Also no-no: Not using $APPNAME (harbour-myapp) as subdirectory of those XDG dirs. If $XDG_*_HOME is not set (and only then), fall back to the default paths as specified by XDG (e.g. $HOME/.config/ for $XDG_CONFIG_HOME, etc..). Or just use QStandardPaths, which will do The Right Thing(tm). If we can fix the offline storage path to be correct everytime, we’ll probably introduce these changes into libsailfishapp, so that application developers don’t have to worry about manually setting this all the time (and you can still override this if you want, but you should not [need to]). HTH :) Thomas ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Sharing a common OfflineStorage DB between multiple Sailfish apps.
Hi Thomas Thank you for your answer. Zitat von Thomas Perl th.p...@gmail.com: If we can fix the offline storage path to be correct everytime, we’ll probably introduce these changes into libsailfishapp, so that application developers don’t have to worry about manually setting this all the time (and you can still override this if you want, but you should not [need to]). Does this not work already? If I did not explicitly call setOfflineStoragePath, the DB was created happily enough in a subdirectory of the app without me having to do anything. Yesterday I experimented further, and arrived at this using QStandardPaths: QString storagePath = QStandardPaths::locate(QStandardPaths::GenericDataLocation, QString(), QStandardPaths::LocateDirectory) + landedcommon; view-engine()-setOfflineStoragePath(storagePath); What are the pros and cons of using QStandardPaths as opposed to XDG Environmental Variables? Zitat von Thomas Perl th.p...@gmail.com: but append the name of your application (harbour-myapp) to the path, so that all your application-specific data ends up there. In my specific case I want this data to be available to a family of apps, which implies that I can't really use the app name as you suggest. I think I could either a) use something like landedcommon as above - which is not the name of any of the apps in the family. b) use the name of the primary app in the family. But this would mean that the secondary apps would have hard-coded references to an external app (not $APPNAME). c) ensure that all apps in the family follow a standard naming pattern (e.g. harbour-landed-pilot, harbour-landed-settings, harbour-landed-recovery), and then create the common directory as a substring of $APPNAME. This raises a greater architectural question: How should families of closely related apps be structured? a) As one package, but with multiple executables b) As separate packages, but able to share stuff within the family of apps: e.g. config data / local storage, shared libraries. The shared libraries is especially important: Given the restrictive harbour rules we have to bundle not-yet-kosher libraries within an app. It would wasteful to have to repeat this for each member of an app family if they use the same libs. In my case each of the apps is a full app in its own right, with a GUI. Others have raised similar questions about app-and-daemon pairs. Grüsse Chris ___ SailfishOS.org Devel mailing list
[SailfishDevel] Sharing a common OfflineStorage DB between multiple Sailfish apps.
Hi all Is it possible to steer where a QML application stores its OfflineStorage Database? I have a family of applications that share a common OfflineStorage Database. This works well on Harmattan, and on the early Sailfish Alphas without me having had to do anything special at all. In the early Sailfish Alphas OfflineStorage DBs were stored in a common location, and thus could be easily shared. /home/nemo/.local/share/data/QML/OfflineStorage/Databases Now on the real Jolla, I find that the standard DB storage location has changed, and DBs are now put in a subdirectory of the application's installation folder. e.g. /home/nemo/.local/share/landed25_QT5/QML/OfflineStorage /home/nemo/.local/share/CreateDBQt5/QML/OfflineStorage This means without some magic, Sailfish apps can no longer share DBs. In C++ there is a property offlineStoragePath, and a setter method setOfflineStoragePath(). http://qt-project.org/doc/qt-5/qqmlengine.html#offlineStoragePath-prop I might be able to use this to change the location of the DB, e.g to one of the Qt StandardLocations: http://qt-project.org/doc/qt-5.0/qtcore/qstandardpaths.html#StandardLocation-enum But setOfflineStoragePath() appears not to be directly available to QML. http://stackoverflow.com/questions/14209585/how-to-set-custom-offline-storage-path-from-javascript-in-qtquick So I guess I could call setOfflineStoragePath in each apps' main cpp file. Or maybe I could even write a declarative plugin to expose setOfflineStoragepath to QML, but that is probably overkill as it would instantiate QQmlEngine - just t o set a path. Or is there a better way? Are there any Harbour entry considerations to an app creating / accessing a DB somewhere other than in its own folder? Thanks Chris ___ SailfishOS.org Devel mailing list
