Created attachment 26634 [details] [review]
Provides functions for retrieving and searching the paths specified by the various $XDG_ enivornment variables

The above patch adds functions for getting and search the xdg base dirs.  Note
that it depends on the patch in bug 139971.

I think the find_file functions should take a callback and loop until it returns
true, instead of relying on file_test_full().

Comments:

 - I think the getters should by G_CONST_RETURN and not return newly
   allocated strings. This requires some extra locking or extension
   of g_get_any_init() but having g_get_home_dir() and 
   g_get_user_data_dir() behave differently is asking for trouble.

   Doc comments should generally describe mememory management
   for string return values one way or the other.

 - As much as we don't abbreviate in general, I'd probably
   s/configuration/config/. (Some existing practice in GScannerConfig
   and GBSearchConfig)

 - Remember that GLib is a cross-platform library. So, the
   documentation should be phrased in more general terms. E.g.
   (not knowing what user_data_dir is for...)
   "Returns a directory in which to store application data
    such as icons that is customized for a particular user".

   Then you can include a link to the XDG basedir spec as what
   it does on Unix. But assuming that the reader knows what
   it is isn't that useful.

 - I don't really like the term "secondary". "system" strikes
   me as more related to the purpose. (Yes, it's settable by
   the  user via envvar, but logically its the part that isn't
   the user dirs)

 - I agree with Matthias that the GFileTest flags are probably
   not what we want. What's the the intended application usage of the
   find() functions? It seems to me that very frequently you
   want merging behavior not overriding behavior.

I think the find() functions are a bit questionable. Looking at the two possible
uses in GTK+, mime and icon themes, in both cases the acutal files to find are
in subdirectories of the xdg_data directories, so find() wouldn't have been
useful anyway. And then there is the question of merging instead of stopping at
the first one which owen mentioned. Both problems could be overcome with the
callback-based api which I proposed earlier, but maybe it is better to just add
the get_dir() functions for now.

Created attachment 30408 [details] [review]
Updated patch

I've removed the find functions and updated things to match the above
suggestions.

Looks alright to me. Just misses the Since: 2.6 in the doc comments.