This is the mail archive of the guile-gtk@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with guile-gobject-0.5.1


Hi Patrick,

I'm replying to the list, because that's where this sort of question
should go. My apologies for being so late. I live in rural Namibia and
my internet is slow as sap, and I only connect every week or so.

On Mon, 30 Jun 2003, Patrick Bernaud wrote:

> I am evaluating the use of your project to wrap around (and extend)
> libraries based on Glib/Gobject/Gtk.

Great!

> However I am having a problem: I do not understand how to manipulate
> gboxed types from guile.
> 
> Here is an example. Let's consider the following definition of the
> type Point in the .def file:
> 
> (define-boxed Point
>   (in-module "MyModule")
>   (c-name "MyPoint")
>   (gtype-id "MY_TYPE_POINT")
>   (fields
>    '("gint" "x")
>    '("gint" "y")
>    )
>   )

Well yes. Interpreted languages need custom wrappers for boxed types. I
suppose the support could somehow use the field names there to access
the structure members... but boxed types are usually a sign that
something is not convenient to represent as an object, on the C side of
things.

If it's a refcounting or a speed issue, then there should be C functions
provided to operate on the object.

If it's represented as a boxed type for convenience and memory usage,
then there's usually a better way to wrap it in scheme. In the case of a
point, I would just have a pair, with the car as x and the cdr as y.

If the type is more complicated than that, representing it as an object
is usually the right way to go.

If you're defining a type in a custom project, why not a GObject?

Indeed, the only thing the defs parser cares about is

> (define-boxed Point
>   (c-name "MyPoint")
>   (gtype-id "MY_TYPE_POINT")
>   )

The other information is superfluous. It's impossible to do at runtime,
although automagic generation of my_module_my_point_set_x () and its
get() counterpart is possible I suppose. It's just a nasty solution.
Gah. I twitch when I think about it. Perhaps someone has thoughts on
this?

> Firstly I do not know how to create such a point from guile. I added a
> constructor to the library and the following to the .def:
> 
> (define-function new_point
>   (c-name "new_point")
>   (is-constructor-of "MyPoint")
>   (return-type "MyPoint*")
>   )
> 
> where my_point has the following prototype :
> 
> MyPoint *new_point();
> 
> and it works. But is it the right way to create a boxed type? Any
> other way?

Yes, that's the right way, if you want it to be an opaque type, only
accessible by C functions. Otherwise you'll have to wrap it specially,
either on the g-wrap level or by providing C functions to wrap it. There
are examples of both in gst-guile, although more documentation on this
would be nice. I'd like to write a nice article about the binding
generator, but I don't have the time right now.

> Sorry if it is obvious, but I did not find the solution in the files
> of the package. There is also few projects around that are using
> guile-gobject, so it is hard to have an example. I know of gstreamer,
> is there any other of interest?

I guess it's not really obvious, I spend so much time staring at this
code I forget what I was and wasn't born with ;) I don't know of any
other projects that are using the bindings. My soundscrape project
(http://ambient.2y.net/soundscrape/) uses the gstreamer bindings a lot
and the wrapper generator a little bit. Things have been changing quite
a bit on the gst-guile side recently, but they seem to be settling down
-- I hope to get a release of those bindings out soon.

But no, I don't know of any other ones. Anyone out there want to speak
up? It's only been since a couple of months ago that the wrapper
generator even exists, so it's not so surprising.

> Thank your for your time.

And thank you for your interest, and apologies again for the delay.

Andy Wingo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]