Overriding QDir::homePath()
-
wrote on 16 Mar 2012, 20:36 last edited by
Take a look at the sources: qfilesystemengine*.cpp files.
On the other hand, this method is already portable so what do you wanna do with it?
-
wrote on 17 Mar 2012, 19:12 last edited by
I did and didn't understand a thing. It's not portable at all because it does something weird and only upon failure uses environment variables.
Please explain what it does (something with tokens).
-
wrote on 17 Mar 2012, 19:39 last edited by
Have you tested this method on different kinds of OS'? What is it returning on Windows/Linux/MacOSX?
-
wrote on 17 Mar 2012, 23:02 last edited by
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().
-
wrote on 18 Mar 2012, 22:00 last edited by tekojo
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
-
wrote on 18 Mar 2012, 22:45 last edited by tekojo
[quote author="Volker" date="1332108047"]
- The value returned by GetUserProfileDirectoryW Windows API call[/quote]
So my question is how does GetUserProfileDirectoryW work. Had I understood it, maybe I could have bypassed it.
- The value returned by GetUserProfileDirectoryW Windows API call[/quote]
-
wrote on 18 Mar 2012, 22:49 last edited by
I don't know the internals. Thats Windows API and I avoid digging into that wherever I can :-) Some Google search may get you more details. Usually that method returns "C:/Documents and Settings/USER" on Win2k/XP and "C:/Users/USER" on Vista/Win7.
-
wrote on 19 Mar 2012, 07:45 last edited by
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.
-
wrote on 19 Mar 2012, 22:50 last edited by
Would you be kind enough to submit that bug report? I don't seem to find such an option anywhere.
Had I understood GetUserProfileDirectoryW, I could have somehow bypassed it without actually modifying the code.
-
wrote on 20 Mar 2012, 08:18 last edited by
The bugsystem is currently at https://bugreports.qt-project.org/secure/Dashboard.jspa
-
wrote on 21 Mar 2012, 09:30 last edited by
-
wrote on 21 Mar 2012, 10:09 last edited by
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.
-
wrote on 22 Mar 2012, 07:24 last edited by tekojo
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
-
wrote on 22 Mar 2012, 07:44 last edited by
Deprecated for Vista and up, but Qt also runs on XP, where the replacement function does not exist yet.
-
wrote on 24 May 2012, 09:55 last edited by
Please answer:
bq. But what advantage does SHGetFolderPath() offer? Can it easily be bypassed?
-
wrote on 27 May 2012, 14:05 last edited by
[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.