Hello list, I discussed a bit with Thiago and some others on irc this evening and have realized that the QStandardPaths patch from [1] and discussion on [2] is trying to solve too many problems at once. I'll list the problems here and some possible solutions to these problems afterwards so we can discuss what are appropriate/purposeful fixes to the problems and get these issues fixed.
QStandardPaths is useful to give paths to various places that are common to all platforms. ConfigLocation tells where configurations should be stored or read from, GenericDataLocation is where data should be, AppDataLocation is where application specific location should be, etc. This works fairly well except where assumptions are made as to where data, configurations, applications, etc. are installed based on one platform. For example applications written with Linux as a target can assume that GenericDataLocation will include /usr/share/ and that ConfigLocation will include ~/.config, then expect those to "just work" when the code is built on other platforms. A few of the KDE Frameworks have been written with these assumptions in mind. One difference between the different platforms that Qt supports is that on some platforms these paths can be easily modified at runtime, while that's not currently possible on all platforms. On Linux GenericDataLocation can be modified at run time by setting XDG_DATA_DIRS, ConfigLocation can likewise be modified at run time by setting XDG_CONFIG_DIRS, but there's not currently a way to set or modify those on Windows or OS X platforms. One possible solution to this for app bundles on OS X is to include the data files any application needs inside the .app itself. The problem with that is that QStandardPaths doesn't look for files inside the .app bundle so if we included icons, data files, etc. in addition to libraries and application icon resources the library code that uses QStandardPaths unmodified to find these files would still fail. The same argument could be used for relative paths on Windows. One use case for the above problem are applications that use data files from their own project and also files from other projects. kdoctools meinproc5 executable is one use case. It uses QStandardPaths to locate the xsl stylesheets required to create documentation. These stylesheets come from kdoctools and also kdelibs4support. These two separate projects could be modified to put their files into /Library/Application Support on OS X so QStandardPaths can find them. This is a tool used by developers, not end users, so installing here shouldn't be a problem. Another use case are data files used by multiple applications. These are stored and safely looked up via QStandardPaths on Linux/Unix in /usr/share followed by some application or data type prefix and the data files themselves. If we want to use these libraries with their accompanying data files on other platforms we either need to rewrite them with #ifdef code to search in different places, which is not possible when using QStandardPaths::locate/locateAll since it only looks in it's standard locations, or search manually for the data files shipped with the library/application or improve QStandardPaths itself. (Note one considered solution to this would be to use DocumentsLocation or one of the other user locations, but this isn't available for applications to install data files that come with the applications into). Proposed and considered solutions: One solution is to use/support XDG_*_DIRS environment variables on all platforms. This has one advantage in that the same tools can be used on all platforms to customize the paths given by the standard. This is ok for developers working on software, but not the best idea for shipping actual software to end users since setting environment variables is not often easy or advisable and has other effects. Note this is the approach of the patch in gerrit, but it's a non-solution because of the above mentioned issues. A second solution is to add some API to QStandardPaths to modify the paths at run time. This would allow libraries to add paths to QStandardPaths' standard paths that it needs in its initialization methods. For example a library that requires data files that it knows are installed to /some/path can add /some/path to the GenericDataLocation via something like QStandardPaths::addCustomPath(GenericDataLocation, "/some/path") and it's subsequent calls to QStandardPaths::locate(GenericDataLocation, "somedatafile") would get the file required. Another similar option would be to always add relative paths based on the application binary or library (or both) so libraries installed inside a .app bundle on OS X could find the data files that are also inside the .app bundle. This way binaries on Windows could also find data files and libraries relative to the installation path of the executable itself, so if end users install MyProgram into D:\Some\Path\Myprogram, and the installer puts the data files beneath that, QStandardPaths api could find the data files wanted. Obviously some changes will be required to any software that has made the above mentioned assumptions about QStandardPaths build systems but if we could also improve QStandardPaths itself in one of the above mentioned solutions that could possibly help make it easier to port applications and libraries from one of Qt's platforms to another. Thoughts, opinions, counterarguments, suggestions? BR, Jeremy [1] https://codereview.qt-project.org/#/c/103277/ [2] https://bugreports.qt.io/browse/QTBUG-44473
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development