Standardpaths library

[Marco Leise via Digitalmars-d-announce]

Am Tue, 07 Apr 2015 17:27:34 +0000
schrieb "FreeSlave" <freeslave93 at gmail.com>:

> On Monday, 6 April 2015 at 21:40:28 UTC, Marco Leise wrote:
> >
> > I believe modern desktops offer enough granularity to cover
> > each of those. For example if I was playing a game on Linux
> > files would go here:
> >
> > /usr/share/[games/] - read-only data files.
> > ~/.cache/ - downloaded archives, precompiled scripts, browser
> >             caches and other files that can be recreated or
> >             fetched again if they were to be deleted
> > ~/.config/ - the user's personal configuration; may be
> >              overriding something in a system directory if
> >              desired
> > ~/.local/share/ - pretty much a catch all for save games,
> >                   user created content that goes beyond the
> >                   scope of config files, highscores,
> >                   highlighting schemes in an IDE, Steam, ...
> >
> > Or the other way around:
> >
> > data               => /usr/share
> > save games         => ~/.local/share
> > downloaded content => ~/.local/share (or ~/.cache)
> > configs            => ~/.config
> >
> > Windows has the Local and Roaming directories, which
> > serve similar but different purposes. E.g. anything machine
> > specific or big must not be in Roaming.
> > So if I generally asked for the config dir, I'd probably expect
> > AppData/Local on Windows and ~/.config on Linux (because I
> > might write a configuration that only works for this machine.)
> > Roaming is interesting for users that have their profiles on
> > servers and might switch to another workstation. So if some
> > configuration is "portable" and you want to create something
> > really fine grained you could offer that directory as an
> > alternative "roaming config dir" (returning null or
> > "~/.config" on Linux).
> > In any case there will be multiple results for some
> > directories (/usr/share, /usr/local/share) and also
> > several standard paths mapping to the same physical directory
> > (user data and user cache both map to AppData/Local on
> > Windows). The user needs to be made aware of this so (s)he
> > doesn't overwrite files in one standard path with files in a
> > supposedly different one.
> >
> > So much for my thoughts on standard paths extreme edition. ;)
> 
> Just found out, there's also special Saved Games directory on 
> Windows. But only starting with Vista, therefore it's not CSIDL, 
> but KNOWNFOLDERID (same as for Downloads). Still I did not find 
> fairly new winapi headers for D. Seems like the most use 
> translation of MinGW headers which stuck at, likely, Windows XP 
> era. Although we could just read some paths from registry 
> avoiding calling SHGetKnownFolderPath, it's way too hacky.

The druntime Windows headers are written on a "as needed"
basis. I don't think anyone would object if you added
something you need, except maybe if it stops druntime from
working in WinXP in general. Don't know about enums that
are only meaningful on Vista and later...

> Currently the only Roaming directories returned by standardpaths 
> library on Windows are Templates and Applications, which is fine. 
> The whole roaming thing is specific to Windows, but it would be 
> useful to add separate function probably.

What do you think about OS agnostic code?

  string configPath =
    standardPath(StandardPath.config, appName);
  string roamingConfigPath =
    standardPath(StandardPath.roamingConfig, appName);

If this worked on Linux it would return the same path for both
calls, but you would avoid introducing version(Windows) switches
in user code.
The appName is there for the common use-case to get the path in
the context of the calling application. If I write a program an
want to open some "images/splash.png" in the installation
directory, I'd expect just the executable directory on Windows,
but "/usr/share/<app name>/" (or one of the overrides) on Linux.
Then again, maybe opening files is outside the scope of your
library. I could imagine it would become a full file system
abstraction layer just to support correct file lookup with all
these /usr/share, /usr/local/share, ~/.local/share and manual
overrides. :p

> The same directory for configs, data and cache locations is the 
> problem. I should mention it in documentation. Though for cache 
> directory it returns AppData/Local/cache the same way as Qt does.

-- 
Marco