[Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere

[Tor Arne Vestbø]

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