On 14-08-22 11:23 AM, Enrico Tröger wrote:
Hi,
lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases.
While most things went fine I noticed one problem:
GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows: in older releases, something GLib 2.28 or 2.26 and older, g_get_user_data_dir() returned c:\users<username>\AppData\Roaming, in newer GLib versions it returns c:\users<username>\AppData\Local.
This affects users who already have a config directory located in <...>\Roaming and Geany would look in <...>\Local now.
This is the change I'm talking about: https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609...
How do we want to handle this?
- continue using the <...>\Roaming directory (and so not using
g_get_user_data_dir() anymore)
If we went this route we could use something like the attached patch[0]. Maybe it's what the linked commit is referring to about proper Windows programs probably not using those GLib functions?
leave the code as it is, resulting in a new complete config for users
add some code to check if a config in <...>\Roaming exists and if so,
move it to <...>\Local
I was thinking about it a bit and it might be good to keep using the "Roaming" one (ie. whatever Win32 API gives as correct dir) since IIUC it allows users on a domain to sync their config between machines on login/logout. As mentioned in the linked commit, the function we use (g_get_user_config_dir()) only changed to match g_get_user_data_dir(), not because it's the actually a better or more appropriate directory.
Anyway, I don't actually care much either way since I rarely use Windows, so any fix is fine to me :)
Cheers, Matthew Brush
[0]: Untested since my win32 geany build environment is once again broken, it might need tweaking win32 version macros before including windows.h or using SHGetFolderPath depending on which versions of Windows we are supporting. Also, the encoding stuff could probably be handled nicer, without going through UTF-8 step.