Facility to get standard paths

[Mario]

It's on my list once some current issues (both SFML and work code) are fixed.

[silverweed]

Is there already any idea how would this be implemented in the API? Global namespaced variables like sf::Path::Home? Also, would we also need some basic functions to check if a path exists/create a directory/etc in a portable way?

[Mario]

You'd most likely construct a "sf::Path" object, which would essentially be a string representation of a path providing some additional features, such as concatenation, access to attributes, etc.

Some mockup stuff, nothing decided or even set in stone yet:

// On Windows this would produce something like "C:\Users\Mario\Documents\My Awesome SFML Game"
// On Linux this would be "~/My Awesome SFML Game"
sf::Path localPath = sf::Path::Documents + "My Awesome SFML Game";

// Load a texture from below working directory
sf::Path assetPath = sf::Path::WorkingDirectory + ".." + "data";
texture.loadFromFile(assetPath + "texture.png");

// Iterate over all file system entries
for (auto &filepath : (localPath + "saves").getFiles())
{
    // ...
}
 

[Nexus]

Variables are a bad idea, they limit the initialization to static functions run at program startup. Use functions and you have the full flexibility: either compute paths on-demand, or at program startup, or on first use.

Furthermore, I think you're underestimating the complexity of a sf::Path in a boost::filesystem::path style manner. Even seemingly simple operations like reducing a path (./dir/.. to .) can hide a lot of pitfalls, see here for example. Things like symbolic links and their platform difference add further to the complexity; in the end SFML would need a filesystem library as a backend. As long as the class doesn't provide much more than string concatenation, we can as well use strings directly.

Jesper Juhl, you said you could provide a proof-of-concept, do you still have the time and motivation?

[Mario]

Meh, I'm too spoiled from being able to write getters.

Path complexity: Haven't taken a look at boost's implementation, but similar to other SFML stuff, I think just the most common basics should be enough. It doesn't have to be a full fledged out implementation where you're able to set or access every tidbit.

Regarding path alternatives resolving to the same real path (like using "." or ".."): On Windows there are API calls to resolve all of these. I'm not sure about the other systems, but there should be something like that I guess.

[dabbertorres]

I made my own Path sort of class implementations. Path reduction was not that hard, as Mario said about API calls, both Windows and Linux have functions to get the "realpath" (as Linux calls it) from a path string.

Linux
Windows

If inspiration is needed/desired/wanted/etc, here's mine. It's not quite complete. I think I didn't get into much permissions stuff on Windows, and I don't have an OSX machine, so that is lacking.

Here's an example of using it:

(click to show/hide)

#include <iostream>

#include "gfs.hpp"
#include "Path.hpp"

int main(int argc, char** argv)
{
#ifdef __linux__
        gfs::Path file("~/Code/GenFS/GenFS.txt");
#elif defined _WIN32
        gfs::Path file("G:/Code/bzHGTeditor/README.md");
#endif

        std::cout << std::boolalpha;
        std::cout << "file exists: " << file.exists() << '\n';
        std::cout << "filename: " << file.filename() << '\n';
        std::cout << "file name: " << file.name() << '\n';
        std::cout << "file ext: " << file.extension() << '\n';
        std::cout << "file parent: " << file.parent() << '\n';
        std::cout << "file last access: " << file.lastAccess().time_since_epoch().count() << '\n';
        std::cout << "file last modify: " << file.lastModify().time_since_epoch().count() << '\n';
       
        std::cout << "file type: ";
        switch(file.type())
        {
                case gfs::Path::Type::File:
                        std::cout << "File\n";
                        break;
                case gfs::Path::Type::Directory:
                        std::cout << "Directory\n";
                        break;
                case gfs::Path::Type::Character:
                        std::cout << "Character\n";
                        break;
                case gfs::Path::Type::Block:
                        std::cout << "Block\n";
                        break;
                case gfs::Path::Type::Pipe:
                        std::cout << "Pipe\n";
                        break;
                case gfs::Path::Type::SymLink:
                        std::cout << "SymLink\n";
                        break;
                case gfs::Path::Type::Socket:
                        std::cout << "Socket\n";
                        break;
                case gfs::Path::Type::Unknown:
                        std::cout << "Unknown\n";
                        break;
        }
       
        std::cout << "$HOME: " << gfs::userHome() << '\n';
        std::cout << "pwd: " << gfs::workingDir() << '\n';
        std::cout << "self path: " << gfs::selfPath() << '\n';
       
        gfs::Path sym("C:/Users/Alec/Desktop/Atom.lnk");
       
        std::cout << "sym: " << sym << '\n';
        std::cout << "sym exists: " << sym.exists() << '\n';
        std::cout << "sym ext: " << sym.extension() << '\n';
        std::cout << "sym parent: " << sym.parent() << '\n';
        std::cout << "sym target: " << gfs::readSymlink(sym) << '\n';
       
        std::cout << "sym type: ";
        switch(sym.type())
        {
                case gfs::Path::Type::File:
                        std::cout << "File\n";
                        break;
                case gfs::Path::Type::Directory:
                        std::cout << "Directory\n";
                        break;
                case gfs::Path::Type::Character:
                        std::cout << "Character\n";
                        break;
                case gfs::Path::Type::Block:
                        std::cout << "Block\n";
                        break;
                case gfs::Path::Type::Pipe:
                        std::cout << "Pipe\n";
                        break;
                case gfs::Path::Type::SymLink:
                        std::cout << "SymLink\n";
                        break;
                case gfs::Path::Type::Socket:
                        std::cout << "Socket\n";
                        break;
                case gfs::Path::Type::Unknown:
                        std::cout << "Unknown\n";
                        break;
        }
       
        gfs::Path dir("~/Documents");
       
        gfs::PathContents children = gfs::contents(dir);
       
        std::cout << "dir perms: " << std::oct << dir.permissions() << '\n';
        std::cout << "dir children:\n";
        for(auto& c : children)
                std::cout << c << '\n';
               
#ifdef __linux__
        gfs::Path newDir("~/Code/GenFS/test/");
#elif defined _WIN32
        gfs::Path file("G:/Code/GenFS/test/");
#endif
       
        gfs::makeDir(newDir);
       
        std::cout << "newDir perms: " << std::oct << newDir.permissions() << '\n';
       
        return 0;
}

PS: Just to make it clear, I'm not intending to step on anyone's toes, or force my project on to you guys. I'm just offering another example of how someone else did it, and a place to get guidance/etc from!

[Nexus]

Maybe asked differently: why not a string, why do we need a dedicated path class?

Keep in mind that we're discussing about getting standard paths here, not about providing filesystem functionality like resolving symlinks, checking the type of a file, etc.

[Jesper Juhl]

I haven't been able to find the time to implement anything yet (although I've implemented all of these in the past for AiX, Solaris, Linux, OS X and Windows, so I know it is possible), but originally I was thinking of something like:

string getExecPath(); // full path to executable (/proc/self/exe)
string getExecDir(); // directory containing executable
string getCWD(); // get current working directory
string getHomeDir(); // users home dir $HOME or %HOME%
string getTempDir(); // /tmp, /var/tmp or %TEMP%
string getDataDir(); // /var/app/foo or %APPDATA%
string getRootDir(); // C:/ or /
 

[AlexAUT]

On Android you would only have 3 path which are useful.

• Assets storage, only available through the assetsmanager because it's inside the APK (zip compressed)
• Internal Storage, it's like a home directory for every app. The path is stored in the ANativeActivity as const char*
• External Storage (SD card or similar), only available if the the app has read/write right for the external folder, which can be set in the manifest. This path is also stored in the ANativeActivity as const char*

I don't know what you should do for the other paths listed in Jesper's last post, because I'm not even sure if you have read access of the root folder etc. (can't test it at the moment).

So you should definitly keep that limitation in your mind when deciding the final API



AlexAUT

[silverweed]

Variables are a bad idea, they limit the initialization to static functions run at program startup. Use functions and you have the full flexibility: either compute paths on-demand, or at program startup, or on first use.

That's true, but since the idea is to get "standard" paths, how complicated should it get to initialize those paths?

I think the question which needs to be sorted out first is: should we just provide those paths (either as objects, variables or getter functions), without bothering to check if they actually exist on the machine SFML is installed on, or should we also ensure the paths we retreive from the API are always valid?

Of course from the user's viewpoint the second choice is the obvious one but, as you said before, it can get pretty complicated to implement, while the first option would be slightly less than trivial if I'm not mistaken.

[Laurent]

That's true, but since the idea is to get "standard" paths, how complicated should it get to initialize those paths?

Since you most likely have to do system calls, doing them at global startup may be impossible on some OSes, like Android and iOS. We must use functions to keep maximum flexibility for implementation.

I think the question which needs to be sorted out first is: should we just provide those paths (either as objects, variables or getter functions), without bothering to check if they actually exist on the machine SFML is installed on, or should we also ensure the paths we retreive from the API are always valid?

Since we don't want to turn SFML into another filesystem library, I'd say just provide the paths.

[silverweed]

Since we don't want to turn SFML into another filesystem library, I'd say just provide the paths.

Yeah, seems the best choice to me too.

[Klaim]

I think the question which needs to be sorted out first is: should we just provide those paths (either as objects, variables or getter functions), without bothering to check if they actually exist on the machine SFML is installed on, or should we also ensure the paths we retreive from the API are always valid?

Since we don't want to turn SFML into another filesystem library, I'd say just provide the paths.

By the way, the unicode mess on Windows might be a major issue for providing any kind of path using just std::string. The basic issue is that if the path have unicode characters, they are provided by the Windows API as either UTF-16 in wide chars, or as ANSI something in chars with non-ansi characters replaced by '?'.
Therefore, you need to use the UTF-16 way on Windows to get something useful, then you need to decide what is the encoding of your output std::string, then convert from one to the other.
The solution boost::filesystem took is to keep the internal representation of the system (UTF-16 on windows) to avoid conversions as much as possible, but then if you as a string from it it will do a dumb conversion OR use a codecvt you provide, which migth do the right thing (or not). Unfortunately there is a strange behaviour where no conversion happen if the type used for storage (char/wchar_t) is same between the two encodings (which mean that a linux OS which is not UTF-8 might have no conversion, or I'm wrong, which might be possible for these kinds of details which I couldn't manage to properly check so far).
In my dayjob I had to work on these kind of issues recently. We chose that any std::string in the API is expected to be UTF-8. We have a path type which currently uses boost:::filesystem::path inside (it's open source by the way but I wouldn't call it a perfect example), then do the conversion when you need a string (so UTF-8) depending on the plateform we are on, so that whatever the boost representation, we always end up with UTF-8.

I don't know what is the policy of SFML regarding encoding of API-provided strings, but if there is none, providing a system paths api will requires that.