Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 -- Get my GPG key from http://www.uvena.de/pub.asc signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 -- Get my GPG key from http://www.uvena.de/pub.asc signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 -- Get my GPG key from http://www.uvena.de/pub.asc --- \tmp\confdir.orig.c Sun Aug 31 14:28:29 2014 +++ \tmp\confdir.c Sun Aug 31 14:29:04 2014 @@ -3,7 +3,7 @@ HRESULT hr; wchar_t path[MAX_PATH]; - hr = SHGetFolderPathAndSubDir(NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, Lgeany, path); + hr = SHGetFolderPathAndSubDirW(NULL, CSIDL_APPDATA | CSIDL_FLAG_CREATE, NULL, SHGFP_TYPE_CURRENT, Lgeany, path); if (SUCCEEDED(hr)) { // GLib always uses UTF-8 for filename encoding on Windows signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 #ifndef __WIN32API_H__ #define __WIN32API_H__ #undef UNICODE #undef _UNICODE #undef VC_EXTRALEAN #undef WIN32_LEAN_AND_MEAN #undef _WIN32_WINNT #define UNICODE 1 #define _UNICODE 1 #define VC_EXTRALEAN 1 #define WIN32_LEAN_AND_MEAN 1 #define _WIN32_WINNT 0x0501 #include windows.h #include commctrl.h #include shellapi.h #include wchar.h #endif // __WIN32API_H__ ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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=adb3e907a47db5ac8537b7cf77c032bf4c90cb14name=waf-1.7# Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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? 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 -- Get my GPG key from http://www.uvena.de/pub.asc signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 gchar *win32_get_user_config_dir(void) { HRESULT hr; wchar_t path[MAX_PATH]; hr = SHGetFolderPathAndSubDir(NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, Lgeany, path); if (SUCCEEDED(hr)) { // GLib always uses UTF-8 for filename encoding on Windows int u8_size = WideCharToMultiByte(CP_UTF8, 0, path, -1, NULL, 0, NULL, NULL); if (u8_size 0) { gchar *u8_path = g_malloc0(u8_size + 1); if (u8_path != NULL WideCharToMultiByte(CP_UTF8, 0, path, -1, u8_path, u8_size, NULL, NULL)) { return u8_path; } } } // glib fallback g_warning(Failed to retrieve Windows config dir, falling back to default); return g_build_filename(g_get_user_config_dir(), geany, NULL); } ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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. Cheers, Matthew Brush diff --git a/wscript b/wscript index 22f347f..c214095 100644 --- a/wscript +++ b/wscript @@ -60,6 +60,11 @@ MINIMUM_GLIB_VERSION = '2.20.0' top = '.' out = '_build_' +def init(x): + pass + +def shutdown(x): + pass mio_sources = set(['tagmanager/mio/mio.c']) ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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. Thanks. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
Am 23.08.2014 um 01:22 schrieb Lex Trotman: On 23 August 2014 04:23, Enrico Tröger enrico.troe...@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 -- Get my GPG key from http://www.uvena.de/pub.asc signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 -- Get my GPG key from http://www.uvena.de/pub.asc signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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. diff --git a/src/main.c b/src/main.c index 279ecdf..cc92906 100644 --- a/src/main.c +++ b/src/main.c @@ -608,7 +608,7 @@ static void parse_command_line_options(gint *argc, gchar ***argv) } else { - app-configdir = g_build_filename(g_get_user_config_dir(), geany, NULL); + app-configdir = utils_get_user_config_dir(); } if (generate_tags) diff --git a/src/utils.c b/src/utils.c index e4c5448..574ca8b 100644 --- a/src/utils.c +++ b/src/utils.c @@ -2078,3 +2078,13 @@ gchar *utils_parse_and_format_build_date(const gchar *input) return g_strdup(input); } + + +gchar *utils_get_user_config_dir(void) +{ +#ifdef G_OS_WIN32 + return win32_get_user_config_dir(); +#else + return g_build_filename(g_get_user_data_dir(), geany, NULL); +#endif +} diff --git a/src/utils.h b/src/utils.h index c4df0bd..7e14099 100644 --- a/src/utils.h +++ b/src/utils.h @@ -289,6 +289,8 @@ GDate *utils_parse_date(const gchar *input); gchar *utils_parse_and_format_build_date(const gchar *input); +gchar *utils_get_user_config_dir(void); + G_END_DECLS #endif /* GEANY_UTILS_H */ diff --git a/src/win32.c b/src/win32.c index eaf5afb..3fe44e6 100644 --- a/src/win32.c +++ b/src/win32.c @@ -1497,4 +1497,34 @@ gchar *win32_get_installation_dir(void) } +gchar *win32_get_user_config_dir(void) +{ + wchar_t wdata_dir[MAX_PATH] = {0}; + + if (SHGetSpecialFolderPath(NULL, CSIDL_APPDATA, TRUE)) + { + /* FIXME: should probably pre-flight the WideCharToMultiByte() call + * to get the proper length since this UTF-8 encoded bytes which will + * probably be more than when encoded as UTF-16/wchar */ + gchar u8data_dir[MAX_PATH+1] = {0}; + + if (WideCharToMultiByte(CP_UTF8, 0, wdata_dir, -1, u8data_dir, MAX_PATH, NULL, NULL)) + { + gchar *locale_data_dir; + + locale_data_dir = g_win32_locale_filename_from_utf8(u8data_dir); + + if (locale_data_dir) + { +gchar *full_path; +full_path = g_build_filename(locale_data_dir, geany, NULL); +g_free(locale_data_dir); +return full_path; + } + } + } + + return g_build_filename(g_get_user_config_dir(), geany, NULL); +} + #endif diff --git a/src/win32.h b/src/win32.h index 72de162c..ad1af90 100644 --- a/src/win32.h +++ b/src/win32.h @@ -71,6 +71,8 @@ gchar *win32_get_installation_dir(void); gchar *win32_expand_environment_variables(const gchar *str); +gchar *win32_get_user_config_dir(void); + G_END_DECLS #endif /* G_OS_WIN32 */ ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Windows GTK Runtime 2.24 and config directory
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) - 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 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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=9d80c361418f94c609840ec9f83741aede7e482c 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 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 23 August 2014 04:23, Enrico Tröger enrico.troe...@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=9d80c361418f94c609840ec9f83741aede7e482c 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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel