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

[Enrico Tröger]

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

[Matthew Brush]

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

[Enrico Tröger]

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

[Enrico Tröger]

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

[Frank Lanitz]

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

[Matthew Brush]

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

[Matthew Brush]

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

[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=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

[Enrico Tröger]

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

[Matthew Brush]

On 14-08-30 05:04 AM, Enrico Tröger wrote:

On 30/08/14 06:47, Matthew Brush wrote:

On 14-08-29 07:24 AM, Enrico Tröger wrote:

On 28/08/14 01:49, Matthew Brush wrote:

On 14-08-27 10:54 AM, Enrico Tröger wrote:

Am 24.08.2014 um 17:18 schrieb Matthew Brush:

On 14-08-22 11:23 AM, Enrico Tröger wrote:

Hi,

lately, I started building a new Windows installer which includes a
recent GTK 2.24 runtime for Windows which need for future releases.

While most things went fine I noticed one problem:

GTK, in detail Glib, changed the way g_get_user_data_dir() works on
Windows:
in older releases, something GLib 2.28 or 2.26 and older,
g_get_user_data_dir() returned
c:\users\username\AppData\Roaming, in
newer GLib versions it returns c:\users\username\AppData\Local.

This affects users who already have a config directory located in
...\Roaming and Geany would look in ...\Local now.

This is the change I'm talking about:
https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c





How do we want to handle this?

- continue using the ...\Roaming directory (and so not using
g_get_user_data_dir() anymore)



If we went this route we could use something like the attached
patch[0].
Maybe it's what the linked commit is referring to about proper Windows
programs probably not using those GLib functions?


- leave the code as it is, resulting in a new complete config for
users

- add some code to check if a config in ...\Roaming exists and
if so,
move it to ...\Local



I was thinking about it a bit and it might be good to keep using the
Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC
it allows users on a domain to sync their config between machines on
login/logout. As mentioned in the linked commit, the function we use
(g_get_user_config_dir()) only changed to match g_get_user_data_dir(),
not because it's the actually a better or more appropriate directory.


Hmm, ok.
We could do it this way either. I have no clue about this roaming
stuff,
just thought it might be good to follow GLib to be consistent with
config dir location. But I don't mind much.

I'd implement this way first, based on your patch, and if we want, we
can change to .../Local later anyway if desired.



I think it's probably the easiest solution, with the least code, and
most compatibility. If you don't feel like coding it yourself, let me
know and I can whip up a (real/working) function to do it. I've been
doing a fair bit of Win32 API coding lately so it's fresh on my mind, I


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



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


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

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

python waf configure
python waf build
python waf install

and everything works fine.



By trial and error (for lack of Waf documentation), I was able to get it
working again. Based on observations alone, it seems that if wscript is
in the root directory of a drive (ie. `X:\wscript`), it requires init
and shutdown functions to be present in the wscript. All I could find
online was some waf source code that provides default implementations
for these functions, but for whatever reason that doesn't happen when
the wscript is in root dir.

See attached patch for what got it going.


Should we commit this?


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


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



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


Cheers,
Matthew Brush

___
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

[Matthew Brush]

On 14-08-29 07:24 AM, Enrico Tröger wrote:

On 28/08/14 01:49, Matthew Brush wrote:

On 14-08-27 10:54 AM, Enrico Tröger wrote:

Am 24.08.2014 um 17:18 schrieb Matthew Brush:

On 14-08-22 11:23 AM, Enrico Tröger wrote:

Hi,

lately, I started building a new Windows installer which includes a
recent GTK 2.24 runtime for Windows which need for future releases.

While most things went fine I noticed one problem:

GTK, in detail Glib, changed the way g_get_user_data_dir() works on
Windows:
in older releases, something GLib 2.28 or 2.26 and older,
g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in
newer GLib versions it returns c:\users\username\AppData\Local.

This affects users who already have a config directory located in
...\Roaming and Geany would look in ...\Local now.

This is the change I'm talking about:
https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c




How do we want to handle this?

- continue using the ...\Roaming directory (and so not using
g_get_user_data_dir() anymore)



If we went this route we could use something like the attached patch[0].
Maybe it's what the linked commit is referring to about proper Windows
programs probably not using those GLib functions?


- leave the code as it is, resulting in a new complete config for users

- add some code to check if a config in ...\Roaming exists and if so,
move it to ...\Local



I was thinking about it a bit and it might be good to keep using the
Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC
it allows users on a domain to sync their config between machines on
login/logout. As mentioned in the linked commit, the function we use
(g_get_user_config_dir()) only changed to match g_get_user_data_dir(),
not because it's the actually a better or more appropriate directory.


Hmm, ok.
We could do it this way either. I have no clue about this roaming stuff,
just thought it might be good to follow GLib to be consistent with
config dir location. But I don't mind much.

I'd implement this way first, based on your patch, and if we want, we
can change to .../Local later anyway if desired.



I think it's probably the easiest solution, with the least code, and
most compatibility. If you don't feel like coding it yourself, let me
know and I can whip up a (real/working) function to do it. I've been
doing a fair bit of Win32 API coding lately so it's fresh on my mind, I


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



I'll try to write it this weekend.




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


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

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

python waf configure
python waf build
python waf install

and everything works fine.



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

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

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



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

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

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



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

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


Thanks,
Matthew Brush

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

___
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

[Matthew Brush]

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

[Matthew Brush]

On 14-08-29 07:24 AM, Enrico Tröger wrote:

On 28/08/14 01:49, Matthew Brush wrote:

On 14-08-27 10:54 AM, Enrico Tröger wrote:

Am 24.08.2014 um 17:18 schrieb Matthew Brush:

On 14-08-22 11:23 AM, Enrico Tröger wrote:

Hi,

lately, I started building a new Windows installer which includes a
recent GTK 2.24 runtime for Windows which need for future releases.

While most things went fine I noticed one problem:

GTK, in detail Glib, changed the way g_get_user_data_dir() works on
Windows:
in older releases, something GLib 2.28 or 2.26 and older,
g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in
newer GLib versions it returns c:\users\username\AppData\Local.

This affects users who already have a config directory located in
...\Roaming and Geany would look in ...\Local now.

This is the change I'm talking about:
https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c




How do we want to handle this?

- continue using the ...\Roaming directory (and so not using
g_get_user_data_dir() anymore)



If we went this route we could use something like the attached patch[0].
Maybe it's what the linked commit is referring to about proper Windows
programs probably not using those GLib functions?


- leave the code as it is, resulting in a new complete config for users

- add some code to check if a config in ...\Roaming exists and if so,
move it to ...\Local



I was thinking about it a bit and it might be good to keep using the
Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC
it allows users on a domain to sync their config between machines on
login/logout. As mentioned in the linked commit, the function we use
(g_get_user_config_dir()) only changed to match g_get_user_data_dir(),
not because it's the actually a better or more appropriate directory.


Hmm, ok.
We could do it this way either. I have no clue about this roaming stuff,
just thought it might be good to follow GLib to be consistent with
config dir location. But I don't mind much.

I'd implement this way first, based on your patch, and if we want, we
can change to .../Local later anyway if desired.



I think it's probably the easiest solution, with the least code, and
most compatibility. If you don't feel like coding it yourself, let me
know and I can whip up a (real/working) function to do it. I've been
doing a fair bit of Win32 API coding lately so it's fresh on my mind, I


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



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

[Enrico Tröger]

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

[Matthew Brush]

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

[Enrico Tröger]

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

[Enrico Tröger]

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

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


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

[Frank Lanitz]

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

[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?


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

[Colomban Wendling]

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

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

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

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