Am Sun, 05 Apr 2015 09:08:12 +0000 schrieb "FreeSlave" <[email protected]>:
> I wrote small library for getting standard paths (like Pictures, > Music) > Here's dub package http://code.dlang.org/packages/standardpaths > And github repo https://github.com/MyLittleRobo/standardpaths > > You can see open issues on github. Please, participate in > discussions if you're interested. The biggest problem now is OS X > support https://github.com/MyLittleRobo/standardpaths/issues/4 > > You can generate documentation with dub build --build=docs. This is indeed useful. I once had a specific use case where I needed the default location for where the assets of my application is stored. On Windows applications come with an installer and install the assets right into the installation directory (usually current directory). On Linux applications store their data in /usr/share/<appname>/. So with a compile-time only template I accessed these as: string asset1 = dirs!"myapp".staticData ~ "/image.png"; Now I realize this is a bit simplistic for several reasons: * On Windows, one might still want to create a subdirectory to separate assets from program code, e.g. "data". * On Linux, as your library shows, data directories are layered like this: ~/.local/share, /usr/local/share, /usr/share * The _actual_ data directory is often passed into the configure script on Linux and no general algorithm could guess it. * An application name would typically become lower-case on Linux while keeping its casing on Windows in e.g. AppData/<appname>. Unsure if that's it, but that could make data file lookup for application "SomeTool" go like this: was the data directory explicitly overridden (e.g. through ./configure or by the programmer)? return overridden_dir; // note: relative directories expand as based on executable directory is this Linux? for (dir in ["${XDG_DATA_HOME}"/sometool, /usr/local/share/sometool, /usr/share/sometool]) is the file in dir ? return dir is this Windows? return executable_path This goes a bit into heuristics and best practices, so it probably doesn't fit with your library that provides clearly defined standard paths from the desktop environment. Aside from that I think it is a common enough use case to lookup assets that ship with your program in the "typical" installation directories. On another note when I ran your 'printdirs' it didn't list a user Fonts or Applications directory. The Applications directory is ok, but I do have a ~/.fonts/ directory and /etc/fonts/fonts.conf says: <!-- the following element will be removed in the future --> <dir>~/.fonts</dir> Fonts in ~/.fonts are listed in LibreOffice. It seems like you do parse /etc/fonts/fonts.conf. Maybe there is a bug in the parser? The whole Applications thing doesn't make much sense on Linux, right? Is that a directory where applications are installed to including their assets? -- Marco
