Message-ID: <44C44FC1.9030608 at rftp.com>
Date: Sun, 23 Jul 2006 21:42:41 -0700
From: Robert Roessler <robertr at rftp.com>
Organization: Robert's High-performance Software
MIME-Version: 1.0
To: LablGTK List <lablgtk at math.nagoya-u.ac.jp>
Subject: Re: GTK 2.8[.18] and other questions
References: <44C34528.1050307 at rftp.com> <20060723.202448.54347944.garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <20060723.202448.54347944.garrigue at math.nagoya-u.ac.jp>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Length: 1868

Thanks, Jacques!

Jacques Garrigue wrote:
>> I have done a source build of LablGTK (CVS from July 6) using GTK 
>> 2.8.18 includes and libraries (on WinXP SP2)... while there were no 
>> apparent build problems, and my few apps seem to run fine when paired 
>> with the 2.8.18 runtime, is this generally a *bad idea*?
> 
> This is supposed to work, but completely unrelated to lablgtk itself.
> If you see any problem, blame the GTK+ crowd...

Oh, I would... ;)  But this one was mostly about saying that it had
been done and works, as well as verifying that when you and the
LablGTK team are asked / respond to questions about what version of
GTK LablGTK works with... it is really just about what *features* are
available.

> ...
> Yes. But note that if the ocaml side looses its pointer, the counter
> will be decremented. If you have code keeping the pointer on the C
> side, it must increment it. If you just pass it to a GTK function, it
> will know what to do with it.

Indeed - I looked at the widget code, and it handles the ref/unref and
signal attach/detach.

> ...
> Val_GtkAny should be enough. It increments the pointer, and creates a
> new pointer from ocaml. The counter is decrements when the pointer is
> garbage-collected.

Cool - I never know when to [not] use the "_sink" versions... ;)

> ...
> By the way, your approach to Selection_mode_val is correct.
> As often this is a windows-only problem (on Unix and OSX, the
> namespace for DLLs is shared,) but if you have ifdefs on CAML_DLL this
> is OK.

Good - the alternative is much more work - changing the generation of
the tag macro lookup stuff to generate *either* the direct table
addresses as now, *or* an accessor call to get the table address from
an exported entry, which would take a per-table enum value in the
CAML_DLL case. :)

Robert Roessler
robertr@rftp.com
http://www.rftp.com