Date: Sun, 23 Jul 2006 20:24:48 +0900 (JST)
Message-Id: <20060723.202448.54347944.garrigue at math.nagoya-u.ac.jp>
To: robertr at rftp.com
Cc: lablgtk at math.nagoya-u.ac.jp
Subject: Re: GTK 2.8[.18] and other questions
From: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <44C34528.1050307 at rftp.com>
References: <44C34528.1050307 at rftp.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: Text/Plain; charset=us-ascii
Content-Length: 3212

Hi,

> 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...

> I have a few non-widget memory management questions (regarding 
> GtkAdjustment specifically, but any generally applicable observations 
> would be welcomed):
> 
> 1) I have created a new "GtkAdjustment" in OCaml using (e.g.)
> 
> GData.adjustment ~upper:678. ()
> 
> 2) So I now have a new OCaml wrapper object wrapping a GTK reference 
> counted object - specifically a GtkAdjustment, correct?

Yes.

> 3) If I want to extract a pointer to the GTK object and pass it in C 
> code to a widget, it seems I should use GData.as_adjustment to obtain 
> the value to pass down to the C external function, but what should it 
> do with it?  Does GtkAdjustment_val() provide the correct handling/ 
> casting of the parameter so that I can then pass that to the widget?

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.

> 4) Now I want to ask the widget for the GtkAdjustment back... note 
> that I expect it to hand me the same pointer that I materialized in 3) 
> above (in my specific widget's case).
> 
> 4a) Precisely what should the C-level wrapper code do with the 
> GtkAdjustment pointer that the widget returns?
>
> 4b) Precisely what should the OCaml code calling the external C 
> wrapper function be expecting back and what should it do with it to 
> [re-]bind it to an OCaml "adjustment" object?

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.

> 4c) Is it important that it be bound to a "canonical" OCaml 
> "adjustment" object IF one is still "live", or can many OCaml objects 
> bind to the SAME GTK [non-widget] object, and everything still works 
> out because of some reference-counting behind the scenes magic?

No. The ocaml side object need not be unique (ocaml-side objects have
no state of their own.) You can see the C side unique id with the
get_oid method, if you need to keep tables of widgets.

> I note that while there seems to be a fair amount of support 
> infrastructure for OCaml handling of "adjustment" objects, I am not 
> using much of it... so I wonder if this is because I am not working 
> with the problems it is intended to solve for me, or is it all 
> actually essential and I am missing out on its coolness?

Not really. The ocaml API code chooses some defaults for adjustment
values, which the C version does not, so your code should be very
light indeed.

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.

   Jacques