[Geany-Devel] Windows GTK Runtime 2.24 and config directory

[Matthew Brush]

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=9d80c361418f94c609840ec9f83741aede7e482c
>
>
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32datadir.patch
Type: text/x-diff
Size: 2429 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20140824/256d7b17/attachment.patch>