Hi,

Since revision 9898 the LongBool type behaves differently. This was done for Delphi compatibility (see log message here
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=9898). In short, if B is LongBool, then "B := true;" sets now B to $ffffffff (while previously it set B to 1).

This has some unexpected results. GTK's (glib and such) gboolean type is defined as equal to LongBool, as it was very comfortable when doing GTK programming. Unfortunately, GTK doesn't officially tolerate gboolean values other than 0 and 1 (see docs
http://library.gnome.org/devel/glib/unstable/glib-Basic-Types.html#gboolean). In most of the cases, this is invisible and things work as before, but:

1. Sometimes we get warnings like

(view3dscene:7005): GLib-GObject-WARNING **: value "TRUE" of type `gboolean' is invalid or out of range for property `do-overwrite-confirmation' of type `gboolean'

(when calling gtk_file_chooser_set_do_overwrite_confirmation(..., true))

2. The really ugly things happen when some library actually assumes that the only valid values are 0 and 1. In particular, this bug bite me bad because GtkGLExt implementation did in one place a comparison of a gboolean value "direct" like "if (direct == TRUE) ....". The "TRUE" in this code comes from Glib headers and is just "1", so passing Pascal's "true" literal ($ffffffff) to this function is treated as false. (With quite catastrophic results in this particular case, as then GtkGLExt gives me "indirect" OpenGL context, which is a software context, without GPU shaders and nearly useless for interesting OpenGL fun.)

IOW, we do have a tricky problem here. The tricky thing is that a lot of GTK-related code may seem to work, but mysteriously fail in particular cases. Anyone sees a nice solution?

Some quick ideas:

1. The solution putting most work on compiler developers would be to implement a new type like "LongBool01", that is assignment-compatible with other boolean types, and internally always guaranteed to be 0 (false) or 1 (true). IOW, LongBool01 would be something like how LongBool behaved before revision 9898 (except LongBool never guaranteed this 0/1 behavior, but it seems we need a type that does guarantee this).

Then define gboolean = LongBool01, and everything magically works everywhere. Users do not have to change anything. Compiler developers have to deal with yet another boolean type inside the compiler.

2. The second option would be to put things in user hands, and force us to correct our code. So gboolean should be defined like

  gboolean = (gfalse = 0, gtrue = 1);

and we need a trivial functions to convert from/to gboolean and normal boolean, like

function ToGBoolean(const A: boolean): GBoolean; inline;
const
  T: array [boolean] of GBoolean = (gfalse, gtrue);
begin
  Result := T[A];
end;

and similar to convert GBoolean to boolean. The uncomfortable thing about this is that all GTK/Glib/GtkGLExt/etc. code will have to be corrected and "infested" with these dummy gboolean<->boolean conversions.

Any ideas?

Michalis

Another possible solution is to do it like what was done in r10577 for xlib.

Jonas

This trick will not work as smoothly, as we have a lot of callbacks for GTK that must return gboolean. All callbacks passed to g_signal_connect and such. And inside this callback, you have to return 0/1 (gfalse/gtrue) to the GTK.

So you cannot hide the troubles with overloading, like it was done for xlib... (Unless you would make "proxy callbacks", overloaded procedure that registers internal callback with GTK, and internal callback calls actual user callback... I guess we don't want to go into such mess?)

Michalis

Maybe you can solve this with an overloaded assignment operator between gboolean and boolean?

Jonas