Message-ID: <43683CF3.8070407 at rftp.com>
Date: Tue, 01 Nov 2005 20:13:39 -0800
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: Alternatives to Val_GtkObject_sink?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Val_GtkObject_sink seems to be the correct way to "wrap" or "register" 
a pointer to a newly instantiated [C-based] widget... as this function 
now has been effectively "un-exported" from dlllablgtk2.dll in the 
Windows binary distribution of LablGTK, what are the available (and 
recommended) options to anyone trying to interface C-written widgets 
(as most of them are) to LablGTK?

Since it is unreasonable to expect any user wanting to merely 
recompile a LablGTK wrapper for an existing widget to be forced to 
perform a full source build of LablGTK just to have normal access to 
this one entry point, I am forced to consider alternatives.

For instance, one could conditionally [re]define Val_GtkWidget_sink as 
a C macro IFF we seem to be building on Windows; in that case, do an 
explicit dynamic look up of the entry point in the DLL and access it 
that way - for non-Windows building, just use Val_GtkWidget_sink 
normally.  This should work, as only access through the normally 
available export library has been made problematic.

One could (I suppose) fully re-implement the LablGTK widget memory 
management for each widget you want to wrap for use in this 
environment, but that seems fraught with potential for error - and 
would not be properly integrated with this functionality as 
implemented by all of the builtin "pre-wrapped" widgets.

What are the consequences of just treating the address of a C widget 
as an "outside-the-heap" pointer and leaving it at that (not wrapping 
it at all)?  Is the only problem going to be some amount of leakage 
per new widget creation, or are there "correctness" (i.e., "crashing") 
issues as well?  I will note that I have just tried this and got a 
crash in libgtk-win32-2.0-0.dll... ;)  The LablGTK infrastructure 
probably expects its own proxy widget wrapper to be in place.

So, we have the presumably workable (if clumsy, inconvenient, and 
verbose) dynamic lookup method, and we have the "full 
reimplementation"... since I do not really take the latter seriously, 
that just leaves the former.  Are there other clean and workable ways 
to attack this that I have not included?

LablGTK is released under the "LGPL-with-linking-exception" (or this 
byproduct of the build process may not even come under the LGPL terms 
at all?), so it should be possible to offer the missing export lib for 
download from some other site - but this would not really help anyone 
without being linked from the LablGTK home page itself.  In any case, 
I will host this myself if it would be of help.

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