sen_ml@eccosys.com writes:
[ I can't send to the list right now, because my mail is currently
delivered thru a backup provider (some power shovel tripped over a
cable or something) and that backup provider is in the ORBS which
Cygnus uses to block spam... Can you forward it for me? Thanks. ]
> gtk-selection-convert itself seems to work
Really? ;-) There is a bug in the way I use scm_intern. I'll fix this
`asap'.
> -- the problem now appears to be that when you register a callback
> for "selection_received", one of the arguments to the callback is
> GtkSelectionData. when the callback call is attempted, there appear
> to be problems because GtkSelectionData doesn't seem to have a
> guile-gtk manifestation
Can you show a short test program so that I can play with it?
> GtkSelectionData's definition (or the underscore version) is:
We have to construct some special interface for GtkSelectionData to
make it safe for guile-gtk. We have to write a function that copies a
GtkSelectionData object and one that frees it again. That should not
be too difficult, but might have performance implications for large
selections.
Background: guile-gtk wants to `own' the objects that it presents to
Scheme. When a callback function is invoked, guile-gtk has to make
sure that it can control the lifetime of all objects that are passed
as arguments to the callback. This is of course to allow the Scheme
program that receives the objects to not care about lifetime issues
itself. Guile-gtk knows how to do this for GtkObject derived types,
for enums flags and the rest of the primitive types like `int',
`string', etc. It does not know how to do this for arbitrary
structures, like GtkSelectionData. We have to tell it by specifying a
`copy' function and a `free' for each such structure.
The copy and free functions can be implemented by doing reference
counting on the original object, when the object allows this. This is
done for GdkFont for example, where the `copy' function is
gdk_font_ref and the `free' function is gdk_font_unref. Sometimes,
real copying is done, GdkColor is an example.
Real copying and reference counting are of course quite different
things.
For GtkSelectionData I think copying is OK, so we need
gtk_selection_data_copy and gtk_selection_data_free.
For accessing the data that is inside a GtkSelectionData object, we
also need to be careful. The atoms can be simple accessed as fields,
but data and length need special treatment, I guess, depending on
format. Or maybe we can just export data as a vector of numbers.
What is the meaning of format, data and length?
> struct _GtkSelectionData
> {
> GdkAtom selection;
> GdkAtom target;
> GdkAtom type;
> gint format;
> guchar *data;
> gint length;
> };
>
> not really knowing what to do, i tried adding:
>
> (define-object GtkSelectionData ()
We need to use `define-boxed' for this.
> (fields
> (atom selection)
> (atom target)
> (atom type)
> (uint format)
> (pointer data)
and `pointer' should not be used.
> p.s. what is the recommended procedure for building guile-gtk from a fresh
> checkout via cvs? right now i'm doing:
>
> % sh autogen.sh
> % ./configure
> % make
This is correct.
> i only figured out the bit about autogen.sh by looking through the
> archives. is there an important bit of documentation i am missing?
No, I really should add this. Sorry for that. The autogen.sh is
becoming more and more commonplace. For example, all of Gnome uses
it.
Hmm, OK, I wont be able to really work on this very soon. Any takers?