On 2015-01-16 2:18 AM, Superfly Jon wrote: > I did write this code and at the time using the windows code directly > was quicker on windows and there were some bugs in the glib threading > code on windows. >
I figured there may have been a reason at one point. I had looked at the GLIB thread code some time ago to see what it does under the hood. The GLIB API effectively is a thin wrapper around the underlying API calls (On MS Windows that is the Win32 threading API calls). So we incur a minor penalty in overhead. The advantage of using GLIB is we don't need to concern ourselves with OS differences. > I expect glib threading support is much better on windows now so > removing the windows code makes sense (especially if it doesn't work > anymore!). > Based on observations of the code it seems that some changes were made to the GLIB side (which is used on *NIX) that were not made to the Win32 code path. Yet another reason to remove one path. > I also notice some checks/two lots of code, if GLIB 2.32 is available. > I would suggest removing those too (which would imply you can only > compile with multiple thread support if you have a new enough version of > Glib). > Yes I know those ifdefs well. Currently I build MS Windows releases using GLIB 2.24 (or there abouts) and developers like Philippe Michel still do builds on older CentoOS/RHEL systems where GLIB and GTK may both be quite bit older. When GLIB 2.32.0 came around they made a number of major changes. The Ifdefs (as you observed) are to retain compatibility with older GLIB versions. If we remove them we limit the versions we can target. I haven't checked in a while but I think we pretty much support any GLIB version above 2.0 and any GTK2(Not GTK3) version above about 2.12 (or maybe it was 2.14). The new MS Windows environment I am working with (MSYS2/MinGW) is currently at GLIB 2.42.1. A few years ago I started to consolidate the ifdefs into one piece of code to deal with differences. At the time I created gtklocdefs.h and gtklocdefs.c, and later added pylocdefs.h and pylocdefs.c (for python). There are a couple of glib related files I created glib-ext.c and glib-ext.h which provide some macros and utility functions (I primarily used them for rewriting the external interface code in the past year). They too do some checks for differing versions of GLIB to handle backwards compatibility. At some point I was considering creating files like gliblocdefs.h and gliblocdefs.c to do something similar to what I did for GTK. Try to capture the differences into a common set of files so that ifdefs for GLIB wouldn't be scattered through the general code. The other option is of course to not support older versions. The question is of course what should we be supporting and how long should we retain backwards compatibility. If one looks closely at the the GTK code you'll also find it littered with #if (USE_GTKUIMANAGER) . This was to start migrating to GTK3 (was never finished). Those ifdefs are quite significant. For the menus and toolbars we were using deprecated GTK APIs. It is preferred to use: https://wiki.gnome.org/GnomeLove/UIManagerTutorial You can build our code base using the GtkUIManager or use the old method. Because I ran out of time a few years back, I never completely transitioned away from the older API. The main outstanding point to deal with it migrating all the string translations. If you build using GtkUIManager most of the menus will appear entirely in English. If one wants to build with GtkUIManager (I haven't tried in some time, so don't even know if it throws errors) you have to add -DGTK_DISABLE_DEPRECATED to CPPFLAGS and then do a configure. Alternatively you can use "-DUSE_GTKUIMANAGER" to only target usage of GTKUIMANAGER. Cleaning this up will cut out a very large extra code path. GtkUIManager has been around since about Gtk 2.4 . The only reason we were using the deprecated functionality is because it was a holdover from the GTK1 days (this predated my involvement on the project). A few years ago I spent a considerable amount of time removing a lot of the deprecated calls throughout the code (but still retaining backwards compatibility with older GTK calls). That was where the gtklocdefs.* files were born. A similar thing applies to supporting Python2 and Python3. I consider this less of an issue since the Python code is limited to a small section of the code base and I have a feeling that people will be supporting both Python2 (2.5+) and Python3 for quite some time. -- Michael Petch GNU Backgammon Maintainer / Developer OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
