MantisBT - Doomseeker
View Issue Details
0003262Doomseeker[All Projects] Bugpublic2017-09-12 03:332019-06-22 10:17
WubTheCaptain 
Zalewa 
lowtweakalways
assignedopen 
x86_64Debian GNU/Linuxbuster/sid
1.1 
 
0003262: Allow $HOME and/or ~/ in file paths
Doomseeker currently requires the file path to be absolute. ~/ and $HOME are not recognized as valid alternatives to /home/<username>, instead /home/<username> (e.g. /home/wub in my case) is written to each configuration. In example for IWAD paths, ~/ and $HOME fail with "Iwad Path error".

This could possibly be extended to other user-configurable file paths, such as server executable path.

  1. Have a defined home folder for an Unix-like user. Mine is /home/wub. This is assumed to be the same as ~/ and $HOME.

  2. Have an IWAD of your choice in your preferred location somewhere in your home folder. Mine is /home/wub/.local/share/games/doom/freedoom.wad.

  3. Open the "Create Game" dialog in Doomseeker. If necessary, configure the minimum necessary to start a server.

  4. Attempt to start a server with IWAD path at preferred location: "/home/wub/.local/share/games/doom/freedoom.wad". This should work.

  5. Attempt to start a server with IWAD path at preferred location: "~/.local/share/games/doom/freedoom.wad". This should work, but fails to an Iwad Path error.

  6. Attempt to start a server with IWAD path at preferred location: "$HOME/.local/share/games/doom/freedoom.wad". This should work, but fails to an Iwad Path error.

Changing the path of my home folder (as a consequence of renaming my username on the local system) means all my previous configurations with IWAD paths in the "Create Game" window and various IWAD/PWAD paths subsequently need fixing to the new location.

If I recall correctly, at worst this means the "Create Game" window fails to list the additional WADs and they will be missing. The paths still exist in the .ini configuration and need to be manually edited to the new paths in a text editor.

In reverse: If I keep my old home location, no change is required if the user wants to hard-type their old path.
No tags attached.
related to 0003354assigned Zalewa Portable mode is portable in name only. 
child of 0003279acknowledged WubTheCaptain List of Debian issues (misc/non-policy) 
log dpkg.log (3,173) 2017-09-12 03:37
https://zandronum.com/tracker/file_download.php?file_id=2204&type=bug
Issue History
2017-09-12 03:33WubTheCaptainNew Issue
2017-09-12 03:37WubTheCaptainNote Added: 0018287
2017-09-12 03:37WubTheCaptainFile Added: dpkg.log
2017-09-12 03:38WubTheCaptainNote Edited: 0018287bug_revision_view_page.php?bugnote_id=18287#r10931
2017-09-21 10:40WubTheCaptainNote Added: 0018355
2017-09-21 10:43WubTheCaptainNote Edited: 0018355bug_revision_view_page.php?bugnote_id=18355#r10987
2017-09-27 18:30ZalewaRelationship addedchild of 0003246
2017-09-27 19:18WubTheCaptainNote Added: 0018398
2017-09-27 19:34WubTheCaptainNote Added: 0018399
2017-09-27 20:01ZalewaNote Added: 0018400
2017-09-27 21:53WubTheCaptainRelationship addedchild of 0003279
2017-09-27 21:54WubTheCaptainRelationship deletedchild of 0003246
2017-10-04 19:27WubTheCaptainCategorySuggestion => Bug
2017-10-05 02:44WubTheCaptainStatusnew => acknowledged
2017-12-11 16:49ZalewaRelationship addedrelated to 0003354
2018-08-27 03:44WubTheCaptainPriorityhigh => normal
2018-08-27 07:31ZalewaAssigned To => Zalewa
2018-08-27 07:31ZalewaStatusacknowledged => assigned
2018-09-04 11:59ZalewaNote Added: 0019489
2018-09-04 12:30ZalewaNote Added: 0019490
2018-10-05 06:17WubTheCaptainPrioritynormal => low
2018-10-05 06:17WubTheCaptainTarget Version => 1.3
2019-06-22 10:17ZalewaTarget Version1.3 =>

Notes
(0018287)
WubTheCaptain   
2017-09-12 03:37   
(edited on: 2017-09-12 03:38)
Tested with Qt5 5.9.1 for original suggestion.

(0018355)
WubTheCaptain   
2017-09-21 10:40   
(edited on: 2017-09-21 10:43)
In addition to what's described in the steps to reproduce, here's some test case guidance for implementers (consider ~/ is /home/user1/):


  • ~user2/something.wad should fetch from /home/user2/something.wad, not /home/user1/user2/something.wad or /home/user1user2/something.wad.

  • ~/foo/~bar/something.wad should fetch from "/home/user1/foo/~bar/something.wad" (second tilde is escaped), not /home/bar/something.wad.

  • On Windows, for compatibility reasons a path beginning with ~ may optionally map to %HOMEDIR% (e.g. C:\Documents and Settings\user1 or C:\Users\user1 in example). Or, %HOMEDIR% could be supported too on Windows (if not already so).



QDir::homePath() may be useful.

(0018398)
WubTheCaptain   
2017-09-27 19:18   
After some consideration, I think this is an upstream issue with QFileDialog in Qt which requires no change in Doomseeker. The change isn't as trivial as I initially thought it would be. It'd be nice to have in Qt for sure.

Should we close this ticket?
(0018399)
WubTheCaptain   
2017-09-27 19:34   
Nevermind. This issue was fixed in Qt 4.8 six years ago:https://bugreports.qt.io/browse/QTBUG-20571 [^]

Seems like something about Doomseeker's use of QFileInfo is wrong, then. QFileInfo in Qt 5 definitely supports tilde.
(0018400)
Zalewa   
2017-09-27 20:01   
I'd still like to have a look around. Maybe I'll find out we're doing something non-standard with paths and it doesn't work everywhere. I'll also think if I want to support env vars resolution in paths.
(0019489)
Zalewa   
2018-09-04 11:59   
Progress update:

I've started working on this and already have a path resolver method that implements some placeholders - it's basic but it should be enough. Documentation excerpt looks like this:


/**
 * @brief Resolution mechanism for paths that can contain dynamically
 * resolvable placeholders.
 *
 * Allowed placeholders are:
 *
 * * `$PROGDIR` (capitals important) resolves to the directory where
 * the application's executable resides.
 * * `$` character followed by a letter or underscore followed optionally
 * by a string of letters, digits or underscores is treated as an env.
 * variable and resolution using such variable is attempted. If there's
 * no matching env. variable, the placeholder resolves to an empty string.
 * Regex: `$[a-zA-Z_][a-zA-Z0-9_]*`.
 * * `~` character at the beginning, followed by a directory delimiter
 * or end of the string is replaced with user's home directory.
 * The `~user` pattern is not allowed and will be treated as
 * a "~user" literal.
 *
 * While Windows platform quotes the env. variables with `%`, DataPaths
 * doesn't follow this pattern and uses the `$` prefix universally for
 * all platforms.
 *
 * @return Path with all placeholders resolved as best as possible.
 * The returned path is not normalized.
 */
QString resolveTemplated(const QString &templatedPath) const;


That was the easy part.

The more difficult part stems partially from the fact that a thing like this needs to be done with full intent from the very first moment of development of the program. Right now, finding all places where the resolution needs to happen as we hit the filesystem and all other places where we need to keep the templated path may prove to be a challenge. This problem isn't only limited to defining the configuration defaults, because user will expect that the placeholders can be used anywhere where path can be input. This is something that can be overcomed, however we need to be careful.

Another cause of problems is QStandardPaths. As much as it has proven to be helpful so far, it will now prove to be that much obstructive. Locations returned from it are absolute. Home dir is not represented as "~", but as an explicit path. To be even more general, Qt doesn't seem to have built-in support for "~" resolution, and anyway even if it had, we still desire to also use our own placehodlers for $PROGDIR and env. variables, which means we need custom resolver anyway. When we retrieve a path from QStandardPaths, do we need to check if it begins from home dir and replace this part with '~'? Where in the code should this happen? In DataPaths? Do we need our own wrapper over QStandardPaths?

Quote from "WubTheCaptain"
QFileInfo in Qt 5 definitely supports tilde.

Do you have any documentation on this? My tests indicate that this is not true.
(0019490)
Zalewa   
2018-09-04 12:30   
I've pushed the work done so far to a separate branch:https://bitbucket.org/Doomseeker/doomseeker/commits/5d30d232dfaba9f8ce5bc07f6f79f65342a37a8e [^]