Standardpaths library

[Marco Leise via Digitalmars-d-announce]

Am Sun, 05 Apr 2015 09:08:12 +0000
schrieb "FreeSlave" <freeslave93 at gmail.com>:

> 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