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

[Matthew Brush]

On 14-08-29 07:24 AM, Enrico Tröger wrote:
> 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 :).
>

I'll try to write it this weekend.

>
>> 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.
>

For me, with Python33 in path, it goes like this:

X:\>python waf configure
No function init defined in X:\wscript

X: is a geany source directory directory on my host machine shared to 
guest and mapped to X:

> 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.
>

Neat, I'll have a read on it this weekend.

BTW, for the 2.24 bump, if you want to update PR# 245[0] as you go, I 
put some fancy checkboxes to track progress :) Probably I missed some 
stuff that needs to be done/tested.

Thanks,
Matthew Brush

[0]: https://github.com/geany/geany/pull/245