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

[Matthew Brush]

On 14-08-30 05:04 AM, Enrico Tröger wrote:
> On 30/08/14 06:47, Matthew Brush wrote:
>> 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 :).
>>>
>>>
>>>> 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.
>>>
>>
>> By trial and error (for lack of Waf documentation), I was able to get it
>> working again. Based on observations alone, it seems that if wscript is
>> in the root directory of a drive (ie. `X:\wscript`), it requires "init"
>> and "shutdown" functions to be present in the wscript. All I could find
>> online was some waf source code that provides default implementations
>> for these functions, but for whatever reason that doesn't happen when
>> the wscript is in root dir.
>>
>> See attached patch for what got it going.
>
> Should we commit this?

I wouldn't, I just wanted to show how I had got it working.

> IIUC, this is a workaround for the drive letter bug in Waf? And so these
> two functions are not needed anymore once the mentioned fix in Waf is
> released?
>

Correct. And yeah, probably better just to stick a new Waf binary (or 
whatever that file is) in the source tree. I can use my patch locally 
until then.

Cheers,
Matthew Brush