summaryrefslogtreecommitdiffstats
path: root/src/corelib/io/qstandardpaths_ios.mm
Commit message (Collapse)AuthorAgeFilesLines
* QStandardPaths: add AppConfigLocation.David Faure2015-01-091-0/+1
| | | | | | | | | | | | | | | | | | | ConfigLocation was erroneously inconsistent, by adding the org name and app name on Windows (unintentionally) and not on Unix (while having subdirs in ~/.config is actually common practice for some XDG desktops) Therefore this adds AppConfigLocation, which always has the org name and app name (while GenericConfigLocation never does). [ChangeLog][QtCore][QStandardPaths] Added QStandardPaths::AppConfigLocation, for application-specific configuration directory. ConfigLocation was inconsistent. Task-number: QTBUG-38872 Task-number: QTBUG-38845 Change-Id: I80fb98f296436261f3996c9df87571c29b06ab35 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Correct QStandardPaths::DataLocation return value for iOSSamuel Gaist2014-10-301-0/+2
| | | | | | | | | | | | | | | | | | | Currently DataLocation returns the same value as DocumentsLocation which doesn't fit the purpose for what should go in this directory. This patch aims to correct that. On a side note, it will also be more inline with OS X current behavior [ChangeLog][QtCore][iOS] Fixed path to QStandardPaths::DataLocation. Until now DataLocation was pointing to the Document directory. With this patch, it will return the more accurate Library/Application Support. Application making use of DataLocation should move these data to the new location. This can be done using the path provided by DocumentLocation as source path. Task-number: QTBUG-42276 Change-Id: I35415643cf8cc7a60528f9b0fb5028ada5deace0 Reviewed-by: Jake Petroules <jake.petroules@petroules.com> Reviewed-by: David Faure <david.faure@kdab.com>
* Add locations AppDataLocation, AppLocalDataLocation to QStandardPaths.Friedemann Kleint2014-04-291-1/+2
| | | | | | | | | | | | | | | | | | | On Windows, DataLocation currently returns the value obtained by passing CSIDL_COMMON_APPDATA to SHGetSpecialFolderPath(). This is the local non-roaming path. For actually storing settings, the roaming path should be used (CSIDL_APPDATA). Introduce new AppDataLocation to return that path and AppLocalDataLocation for the local path and deprecate DataLocation. [ChangeLog][QtCore][QStandardPaths] QStandardPaths now has new enumeration values AppDataLocation, AppLocalDataLocation to be able to differentiate between roaming and local paths on the Windows operating system. DataLocation is deprecated in favor of AppDataLocation. Task-number: QTBUG-38483 Change-Id: Ib1de8c7031a863ed5eac10c747de6f7ff1a090c7 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com> Reviewed-by: David Faure <david.faure@kdab.com>
* QStandardPaths: add GenericConfigLocationDavid Faure2013-11-051-0/+1
| | | | | | | | | | | | | | | | This is what ConfigLocation was meant to be. A directory shared by all applications. Unfortunately when I wrote the fallback on Windows, I picked DataLocation (which is app-specific) instead of GenericDataLocation (which is shared between apps). This makes it impossible to have config files shared between apps, e.g. for libraries. It also makes ConfigLocation quite inconsistent (on Windows one cannot use it to load another app's config file, while it works everywhere else). All this is fixed by GenericConfigLocation, which is shared between apps. Change-Id: I23a755131061d4fea01e13dd1038fbd8ef333a5d Reviewed-by: Alex Richardson <arichardson.kde@googlemail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* iOS: Add standard paths implementation for iOSIan Dean2013-10-301-0/+135
A standard paths implementation for iOS. The APIs used on iOS require that the source file be "Objective-C++" (with a .MM extension), as there are no APIs available in C++ for this. The implementation complies with the latest documentation on standard paths. Change-Id: I349d3c5d4ddb6fb1297a45dc9ae26b56ac528abb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: David Faure <david.faure@kdab.com>