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
