Overriding QDir::homePath()
-
From doc :
bq. Under Windows this function will return the directory of the current user's profile. Typically, this is:
C:/Documents and Settings/Usernamebq. Under non-Windows operating systems the HOME environment variable is used if it exists, otherwise the path returned by the rootPath().
-
On Windows, the user directory is searched in the following order, the first method that returns a valid[1] path is used:
- The value returned by GetUserProfileDirectoryW Windows API call
- The value of USERPROFILE environment variable
- The value of HOMEDRIVE + HOMEPATH environment variables
- The value of HOME environment variable
- The value of SystemDrive environment variable (no check for existence)
- "C:/" (hard coded as last resort, no check for existence)
fn1. valid means the method returns a value and the directory denoted by that value does exist
-
-
Just to let me get this right: you want to modify the behaviour of an existing binary, you are not a developer who wants to modify its own sourcecode or application.
Well, I guess you are left with four options then, in the order of work and stress involved
- recompile the binary not using QDir::homePath() or
- file a bug report or a merge request which modifies the behaviour of QDir::homePath() in a way that <code>%USERPROFILE%</code> takes precedence over GetUserProfileDirectoryW or
- distribute the binary with a patched set of the Qt libraries which modify the behaviour of QDir::homePath() or
- hook GetUserProfileDirectoryW directly to modify its behaviour.
I'm not quite sure as of right now but I tend to say that <code>%USERPROFILE%</code> and <code>%HOME%</code> should take precedence over GetUserProfileDirectoryW just to cover cases like yours (where you want to temporarily redirect the home directory) and to get a more consistent cross-platform behaviour.
-
The bugsystem is currently at https://bugreports.qt-project.org/secure/Dashboard.jspa
-
-
Regarding the text in your bugreport:
bq. Various standalone portable softwares could have been forced to become portable, if only they hadn't stored their data in a path that involves QDir::homePath().
A sane Qt application doesn't use homePath() for that, but calls QDesktopServices::storageLocation() with, for example, QDesktopServices::DataLocation as argument. These methods do not use homePath() under the hood (or only as a last resort), but call SHGetFolderPath() on Windows, which is native Windows API again.
-
The OP links to at least 2 programs that do this. Well, if their authors knew what they were doing, they would have accepted an "/ini=" command line parameter in the first place.
But what advantage does SHGetFolderPath() offer? Can it easily be bypassed?
BTW:
bq. Deprecated
- SHGetFolderPath function, Microsoft MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx
-
[quote author="lwcorp" date="1337853314"]Please answer:
bq. But what advantage does SHGetFolderPath() offer? Can it easily be bypassed?[/quote]
Advantage: it is official API, although deprecated. But as Andre already mentioned, as long as Qt is running on XP, one will have to use it, as the replacement isn't there.
Bypassing: I don't know, as I never had a need to do this.