You are probably right.

Created attachment 163060 [details] [review]
Use CSIDL_APPDATA instead CSIDL_PERSONAL in g_get_user_data_dir()

I think I retract my comment #1.

Is the main point in this bug that the documentation talks about "virtual" folder, making it sound scary? No need to be scared of that, on both XP and Windows 7 the return value from g_get_user_data_dir() is a fully valid pathname to a directory that can be used quite normally in code.

I understand that in bug #592566, which discusses a case where an application-specific (or actually, library-specific) *directory* is created, the end-user expectation would be for that to be created under CSIDL_APPDATA. But what about an application that wants to create a freestanding *document*? Shouldn't that by default be created in CSIDL_PERSONAL? That's what Windows applications designed for Windows do.

With "document" here I mean something that in the filesystem is an isolated file, and which appears fully visible in the desktop environment / file browser / etc as a "document" that can typically be double-clicked to start the associated application editing or viewing it.

An application-specific directory, on the other hand, should ideally be hidden from casual inspection by the user.

The XDG specification is so extremely loosely written that it is hard to say what XDG_DATA_DIRS means.

Also as far as I can see, the directory .gegl-0.0 (the example in bug #592566) falls clearly into the second category, something that should be hidden from casual browsing by the user. (Of course, it's name starting with a period, also indicated that in traditional POSIX shells.)

So is the real problem here that XDG, and thus GLib, doesn't differentiate between the use cases of a folder for a user's documents, and a folder for a user's application-specific data that the user is not supposed to be able to open?

On the other hand, I do see that the documentation for g_get_user_data_dir() specifically talks about "application data" and mentions as examples icons customized for the user. So from that it indeed sounds as if it means a place for files not intended to be casually browsable and editable by the user, and CSIDL_APPDATA would be the more correct place.

(On the other hand, how is that then different from what g_get_user_config_dir() returns? And in that case, why is there then no XDG environment variable, or GLib function, to indicate where to store user-specific editable documents? Surely not in g_get_home_dir()?)

The problem with these functions is that they are so loosely specified, and refer to the somewhat useless XDG Base Directory specification. The documentation and the XDG Base Directory "specification" have been written to justify an existing convention, without actually specifying what the convention is, or what end-user visible appearance the convention wants to achieve.

(In reply to comment #4)
> And in that case, why is there then no XDG
> environment variable, or GLib function, to indicate where to store
> user-specific editable documents? Surely not in g_get_home_dir()?)

For this case I think the correct solution is to use:

g_get_user_special_dir (G_USER_DIRECTORY_DOCUMENTS)

Ah ok. So is the consensus then among you that g_get_user_data_dir() and g_get_user_config_dir() should return the same string on Windows, the CSIDL_APPDATA folder, which maps to C:\Users\<username>\AppData\Roaming on Windows 7? Or CSIDL_LOCAL_APPDATA, which maps to C:\Users\<username>\AppData\Local ?

Whichever we choose, somebody is bound to complain sooner or later. Is there any corresponding "local" vs. "roaming" user-specific data on Linux? I guess not... I don't understand fully the difference on Windows. Is the AppData\Roaming folder copies to each machine a user logs in on in a network environment?

And, an application (or library) *really* caring for Windows (and having developer resources for that) won't use these GLib functions anyway...

Let's take a look what others do in this case:

http://doc.qt.nokia.com/4.7/qdesktopservices.html

Seems that there is not a value to retrieve the config folder (g_get_user_config_dir()), so we can point in the docs that g_get_user_config_dir() == g_get_user_data_dir() in windows platform, and recomend only the use of g_get_user_data_dir().


QDesktopServices::DataLocation is our g_get_user_data_dir():

They use XDG_DATA_HOME in X11: http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/util/qdesktopservices_x11.cpp#line148

And CSIDL_LOCAL_APPDATA in win: http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/util/qdesktopservices_win.cpp#line193

OK. So let's follow Qt's lead then. (I would be the first to admit they have better cross-platform support than GLib and GTK+. Actually I don't know, never used Qt, but I strongly suspect so.)

Is this a "bug" that should be fixed also in the stable branch, or more an "enhancement" that should be fixed in master only?

BTW, if any of you silently following this bug oppose this change, now is the time to speak up!

*** Bug 592566 has been marked as a duplicate of this bug. ***

OK, no objections, fixed now in GLib master.

commit 9d80c361418f94c609840ec9f83741aede7e482c
Author: Tor Lillqvist <tml@iki.fi>
Date:   Thu Oct 14 22:47:25 2010 +0300

    Use CSIDL_LOCAL_APPDATA on Windows

    Make g_get_user_data_dir() return the CSIDL_LOCAL_APPDATA folder on
    Windows, and not CSIDL_PERSONAL. On Windows 7, that corresponds to the
    subfolders AppData\Local vs. Documents under the profile ("home")
    folder. This matches what Qt does, for instance, and has been widely
    requested.

    Also make g_get_user_config_dir() return this and not the (roaming)
    CSIDL_APPDATA folder. The reason for this change is that it would be
    surprising and hard to justify if g_get_user_data_dir() returned the
    local application data folder while g_get_user_config_dir() would
    return the roaming one. Nothing in the function names or the XDG specs
    suggests that any roaming vs. local dichotomy would be involved.

    Document the new semantics and the fact that these two functions now
    return the same directory on Windows.

    Note that in reality, code that really truly wants to support Windows
    as well as possible probably will not use these GLib functions anyway,
    but Win32 APIs directly to be sure what it is doing...

    Should hopefully satisfy complaints in bug #620710 and related bugs.

*** Bug 634487 has been marked as a duplicate of this bug. ***

I realize that it's kind of late (by a year) to complain, but this change breaks applications which use g_get_user_config_dir() - after glib upgrade config files got lost. (I discovered it only now because I am still using gtk-2.16 on windows).

The reason why I do complain is this: "code that really truly wants to support Windows as well as possible probably will not use these GLib functions anyway". How do you tell which functions are good to use and which aren't? It's certainly not in the docs :)