Re: [Bug-gnubg] MS Windows / Multi-Threading / Code simplification

[Michael Petch]

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