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

[Enrico Tröger]

On 28/08/14 01:49, Matthew Brush wrote:
> On 14-08-27 10:54 AM, Enrico Tröger wrote:
>> Am 24.08.2014 um 17:18 schrieb 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.
>>
>> Hmm, ok.
>> We could do it this way either. I have no clue about this roaming stuff,
>> just thought it might be good to follow GLib to be consistent with
>> config dir location. But I don't mind much.
>>
>> I'd implement this way first, based on your patch, and if we want, we
>> can change to .../Local later anyway if desired.
>>
> 
> I think it's probably the easiest solution, with the least code, and
> most compatibility. If you don't feel like coding it yourself, let me
> know and I can whip up a (real/working) function to do it. I've been
> doing a fair bit of Win32 API coding lately so it's fresh on my mind, I

I don't mind, if you like to do it, I'd be happy to test the result :).


> just can't get Waf working with my new setup because Geany's git tree is
> not on the C: drive anymore (it's on a mapped/shared drive), which makes
> Waf choke with errors about "no init function" (have you ever
> experienced this error?).

Nope.
I remember on a prevous Windows VM I had Geany and library includes and
libs on a C: drive while the system itself (Windows, Python, ...) was
installed on a E: drive. That worked well though both were local drives,
nothing mapped.

How do you start waf?
On my current setup, I added c:\python27 to $PATH, so in the Geany git
clone I just type:

python waf configure
python waf build
python waf install

and everything works fine.

I don't remember if I already mentioned that I started to document the
Windows build stuff (as promised months ago :D):

https://wiki.geany.org/howtos/win32/build

While not yet complete, the basic stuff should be covered.

Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.geany.org/pipermail/devel/attachments/20140829/4a8f616a/attachment.sig>