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)
- 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'd implement the last choice if there are no objections. This is not nice because we implement again some magic "config directory move" code but at least the user won't notice that GLib change.
Regards, Enrico
Hey,
Le 22/08/2014 20:23, Enrico Tröger a écrit :
lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases.
Nice :)
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...
Oh my. And we though it was a supporting library :)
How do we want to handle this?
- continue using the <...>\Roaming directory (and so not using
g_get_user_data_dir() anymore)
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'd implement the last choice if there are no objections. This is not nice because we implement again some magic "config directory move" code but at least the user won't notice that GLib change.
Agreed, both with solution and remark.
Regards, Colomban
On 23 August 2014 04:23, Enrico Tröger enrico.troeger@uvena.de 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.
Hi Enrico,
Do you have access to any reputation or signing certificates for windows applications? http://blogs.msdn.com/b/ie/archive/2012/08/15/10339518.aspx
Might improve the windows experience.
Cheers Lex
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)
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'd implement the last choice if there are no objections. This is not nice because we implement again some magic "config directory move" code but at least the user won't notice that GLib change.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 23.08.2014 um 01:22 schrieb Lex Trotman:
On 23 August 2014 04:23, Enrico Tröger enrico.troeger@uvena.de 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.
Hi Enrico,
Do you have access to any reputation or signing certificates for windows applications? http://blogs.msdn.com/b/ie/archive/2012/08/15/10339518.aspx
Might improve the windows experience.
Probably. Though I personally don't intend to get such a certificate or get involved into this matter deeper.
As long as I build the Windows installers and other binaries, I happily will continue signing the binaries with my private CACert certificate which I do since years already.
As the link above states, this also will help to build that "reputation", in whatever way that works....
Regards, Enrico
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.
[snip]
- add some code to check if a config in <...>\Roaming exists and if so,
move it to <...>\Local
I'd implement the last choice if there are no objections. This is not nice because we implement again some magic "config directory move" code but at least the user won't notice that GLib change.
Sounds fine to me, even just a one-time dialog telling the user about the change would be useful. Either way the code be put inside win32.c and guarded with an #ifdef G_OS_WIN32 so it doesn't mess up unrelated source files.
FWIW, I don't think this is the first time the config directory moved. Even between WinXP and Windows7 the actual directory used had changed, causing a little confusion (for me at least).
Cheers, Matthew Brush
Am 23.08.2014 um 02:26 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.
[snip]
- add some code to check if a config in <...>\Roaming exists and if so,
move it to <...>\Local
I'd implement the last choice if there are no objections. This is not nice because we implement again some magic "config directory move" code but at least the user won't notice that GLib change.
Sounds fine to me, even just a one-time dialog telling the user about the change would be useful. Either way the code be put inside win32.c
Ok. I don't mind much. I'd suggested to try to move the config directory and only if it doesn't work to show a dialog. I guess since we are deep in the Windows directory structure at this stage, we can quite safely assume the Local directory exists if the Roaming directory exists as well?
and guarded with an #ifdef G_OS_WIN32 so it doesn't mess up unrelated source files.
Full ACK.
FWIW, I don't think this is the first time the config directory moved. Even between WinXP and Windows7 the actual directory used had changed, causing a little confusion (for me at least).
Yeah and on non-Windows we had the change from ~/.geany to ~/.config/geany.Config directory changes suck.
Regards, Enrico
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.
On 14-08-24 08:18 AM, Matthew Brush wrote:
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.
And looking at the code, could never work as is, but the main point is using our own wrapper function to get user config dir, it would need to be written properly :)
Cheers, Matthew Brush
Am 24.08.2014 um 17:24 schrieb Matthew Brush:
And looking at the code, could never work as is, but the main point is using our own wrapper function to get user config dir, it would need to be written properly :)
And having in mind they will add some more magic with later versions of Windows I'm sure this is a bad idea.
Cheers, Frank
On 14-08-24 08:42 AM, Frank Lanitz wrote:
Am 24.08.2014 um 17:24 schrieb Matthew Brush:
And looking at the code, could never work as is, but the main point is using our own wrapper function to get user config dir, it would need to be written properly :)
And having in mind they will add some more magic with later versions of Windows I'm sure this is a bad idea.
What magic in what versions? And what's different if the Win32 API call is in GLib vs Geany?
Cheers, Matthew Brush
Am 24.08.2014 um 21:08 schrieb Matthew Brush:
On 14-08-24 08:42 AM, Frank Lanitz wrote:
Am 24.08.2014 um 17:24 schrieb Matthew Brush:
And looking at the code, could never work as is, but the main point is using our own wrapper function to get user config dir, it would need to be written properly :)
And having in mind they will add some more magic with later versions of Windows I'm sure this is a bad idea.
What magic in what versions? And what's different if the Win32 API call is in GLib vs Geany?
I was referring to the layout changes in past and wanted to they, that I'm there will be some changes with further versions. Maybe wasn't very clear about that ;)
cheers, Frank
On 14-08-31 08:49 AM, Frank Lanitz wrote:
Am 24.08.2014 um 21:08 schrieb Matthew Brush:
On 14-08-24 08:42 AM, Frank Lanitz wrote:
Am 24.08.2014 um 17:24 schrieb Matthew Brush:
And looking at the code, could never work as is, but the main point is using our own wrapper function to get user config dir, it would need to be written properly :)
And having in mind they will add some more magic with later versions of Windows I'm sure this is a bad idea.
What magic in what versions? And what's different if the Win32 API call is in GLib vs Geany?
I was referring to the layout changes in past and wanted to they, that I'm there will be some changes with further versions. Maybe wasn't very clear about that ;)
Using the Win32 API ensures that whenever the layouts change it won't break as Windows will redirect them to the correct location or the Win32 API will internally deal with it. Using GLib functions won't give that level of compatibility (see $subject).
Cheers, Matthew Brush
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=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.
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.
Thanks.
Regards, Enrico
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=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.
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 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?).
Cheers, Matthew Brush
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=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.
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
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=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.
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
On 14-08-29 04:19 PM, Matthew Brush wrote:
On 14-08-29 07:24 AM, Enrico Tröger wrote:
On 28/08/14 01:49, Matthew Brush wrote:
[snip]
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 asked about it on Waf's IRC channel and gave some details and it turned out to be a bug in Waf with path joining and Windows drive letters. Fix was pushed within an hour :)
https://code.google.com/p/waf/source/detail?r=adb3e907a47db5ac8537b7cf77c032...
Cheers, Matthew Brush
Hey,
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 for the reminder, I put some noise on it :).
The Windows related checkbox can be checked once we got a fresh installer from GIT master and someone tested it on a non-developer machine (to ensure everything really necessary is included and working).
Regards, Enrico
On 14-08-29 07:24 AM, Enrico Tröger wrote:
[snip]
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 :).
Attached is a function that works standalone, it could drop into the previous patch where the untested/working function was. I have only tested on WinXP. If you don't feel like putting it together manually, I can eventually commit it all together properly once I figure out my build system issues.
Cheers, Matthew Brush
On 30/08/14 03:04, Matthew Brush wrote:
On 14-08-29 07:24 AM, Enrico Tröger wrote:
[snip]
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 :).
Attached is a function that works standalone, it could drop into the previous patch where the untested/working function was. I have only tested on WinXP. If you don't feel like putting it together manually, I can eventually commit it all together properly once I figure out my build system issues.
Tested on Windows 7:
I had to change the function to its multibyte variant:
SHGetFolderPathAndSubDirW
Otherwise it spat out compiler warnings and the resulting config directory was:
㩃啜敳獲敜牮捩屯灁䑰瑡屡潒浡湩屧g旄
:).
Additionally, I had to add the flag CSIDL_FLAG_CREATE so that the ...\Roaming\geany folder is created initially if it doesn't exist yet. Without that flag, SHGetFolderPathAndSubDirW() would fail if the folder doesn't exist. Alternatively we could maybe use the flag CSIDL_FLAG_DONT_VERIFY since we create the folder in Geany at a later point anyway. Though I didn't test this flag because I guess it's better if Windows creates this special folder.
Attached is the trivial diff of my changes to your confdir.c.
So, if my modifications work also on your Windows XP, I'd say go ahead and commit your changes and I will start to build the installer.
Regards, Enrico
On 14-08-31 07:38 AM, Enrico Tröger wrote:
On 30/08/14 03:04, Matthew Brush wrote:
On 14-08-29 07:24 AM, Enrico Tröger wrote:
[snip]
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 :).
Attached is a function that works standalone, it could drop into the previous patch where the untested/working function was. I have only tested on WinXP. If you don't feel like putting it together manually, I can eventually commit it all together properly once I figure out my build system issues.
Tested on Windows 7:
I had to change the function to its multibyte variant:
SHGetFolderPathAndSubDirW
That's the wide character variant, the ASCII one is the A function. You should be able to just use the non-char-specific one as long as we're telling the Win32 API we're using the wide API (I assumed we were since I saw other code in win32.c using wide characters). You need to #define UNICODE or _UNICODE (I always forget) before including "windows.h" to make it work normally/automagically.
Attached is the header I always use to wrap up the Win32 API include/defining weirdness that seems to "just work" with Unicode without any fuss.
Otherwise it spat out compiler warnings and the resulting config directory was:
㩃啜敳獲敜牮捩屯灁䑰瑡屡潒浡湩屧g旄
:).
Additionally, I had to add the flag CSIDL_FLAG_CREATE so that the ...\Roaming\geany folder is created initially if it doesn't exist yet. Without that flag, SHGetFolderPathAndSubDirW() would fail if the folder doesn't exist.
That should be fine I would think. I just assumed other Geany code dealt with creating it.
Alternatively we could maybe use the flag CSIDL_FLAG_DONT_VERIFY since we create the folder in Geany at a later point anyway. Though I didn't test this flag because I guess it's better if Windows creates this special folder.
Not sure, I suppose it's fine either way.
Attached is the trivial diff of my changes to your confdir.c.
So, if my modifications work also on your Windows XP, I'd say go ahead and commit your changes and I will start to build the installer.
Will test soon, but just looking they should be fine.
Cheers, Matthew Brush
On 01/09/14 01:25, Matthew Brush wrote:
On 14-08-31 07:38 AM, Enrico Tröger wrote:
On 30/08/14 03:04, Matthew Brush wrote:
On 14-08-29 07:24 AM, Enrico Tröger wrote:
[snip]
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 :).
Attached is a function that works standalone, it could drop into the previous patch where the untested/working function was. I have only tested on WinXP. If you don't feel like putting it together manually, I can eventually commit it all together properly once I figure out my build system issues.
Tested on Windows 7:
I had to change the function to its multibyte variant:
SHGetFolderPathAndSubDirW
That's the wide character variant, the ASCII one is the A function. You should be able to just use the non-char-specific one as long as we're telling the Win32 API we're using the wide API (I assumed we were since I saw other code in win32.c using wide characters). You need to #define UNICODE or _UNICODE (I always forget) before including "windows.h" to make it work normally/automagically.
Nice to know, thanks. So far we used the wide character variants explicitly in src/win32.c at some places and the default of some functions on the rest. Though at least for those places I wrote, there was no particular reason apart from getting it to work.
Attached is the header I always use to wrap up the Win32 API include/defining weirdness that seems to "just work" with Unicode without any fuss.
Maybe we can incorporate this into Geany src/win32.c at some point but probably in a separate step, this would get too big for this change I guess.
Otherwise it spat out compiler warnings and the resulting config directory was:
㩃啜敳獲敜牮捩屯灁䑰瑡屡潒浡湩屧g旄
:).
Additionally, I had to add the flag CSIDL_FLAG_CREATE so that the ...\Roaming\geany folder is created initially if it doesn't exist yet. Without that flag, SHGetFolderPathAndSubDirW() would fail if the folder doesn't exist.
That should be fine I would think. I just assumed other Geany code dealt with creating it.
Geany would create it later but without the CSIDL_FLAG_CREATE the SHGetFolderPathAndSubDirW() would error out if the directory doesn't exit and so Geany wouldn't continue.
Regards, Enrico
Hey,
Attached is the trivial diff of my changes to your confdir.c.
So, if my modifications work also on your Windows XP, I'd say go ahead and commit your changes and I will start to build the installer.
Will test soon, but just looking they should be fine.
*little-ping*
Or, if you are busy but agree, I could commit the changes myself.
Regards, Enrico
On 14-09-30 06:40 AM, Enrico Tröger wrote:
Hey,
Attached is the trivial diff of my changes to your confdir.c.
So, if my modifications work also on your Windows XP, I'd say go ahead and commit your changes and I will start to build the installer.
Will test soon, but just looking they should be fine.
*little-ping*
Or, if you are busy but agree, I could commit the changes myself.
If you don't mind to commit them yourself, that would go faster :)
Cheers, Matthew Brush
On 01/10/14 21:17, Matthew Brush wrote:
On 14-09-30 06:40 AM, Enrico Tröger wrote:
Hey,
Attached is the trivial diff of my changes to your confdir.c.
So, if my modifications work also on your Windows XP, I'd say go ahead and commit your changes and I will start to build the installer.
Will test soon, but just looking they should be fine.
*little-ping*
Or, if you are busy but agree, I could commit the changes myself.
If you don't mind to commit them yourself, that would go faster :)
Alright, committed as: 3e089e
Updated Windows installers for testing will follow.
Regards, Enrico
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=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.
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.
Cheers, Matthew Brush
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=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.
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? 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?
Regards, Enrico
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=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.
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