Thanks for the write up Jeremy, On 24/02/15 07:24, Jeremy Whiting wrote: > 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. Just to clarify, as the wording of this paragraph was a bit funky: any assumption about what QStandardPaths returns is bound to fail when targeting multiple platforms, so "applications written with Linux as a target" can and should _not_ assume anything about the paths, and will fail on non Linux platforms if they do. I think that's what you're saying as well, I just read it a bit weird the first time around :) > 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. This should be fixed for OS X (and iOS). ~/Library/Application Support can be used for installed application data, but is most typically used for generated application data that is not directly user documents (which should live in ~/Documents), so the app bundle should be one of the paths returned by QStandardPaths. > 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. This is the correct approach. Cross platform deployment (installing files into /usr/share on Linux and ~/Library/Application Support on OS X) + cross platform runtime lookup through QStandardPaths. Qt is lacking on providing the former, but that doesn't mean it's not the right approach. > 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. The OS X equivalent is to install the shared data files into ~/Library/Application Support/<someprefix> and look them up using QStandardPaths::GenericDataLocation. > > Proposed and considered solutions: None of these seem needed if you install the data to the right location on the given platform? > Obviously some changes will be required to any software that has made > the above mentioned assumptions about QStandardPaths build systems Yes. > 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. We should put effort into improving how Qt helps out with the cross platform deployment/installation phase, not into assuming the deployment is the same on all platforms and working around it in the runtime lookup phase. Tor Arne _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
