public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: guile-gtk@sources.redhat.com
Cc: Patrick Bernaud <b-patrick@wanadoo.fr>
Subject: Re: Problem with guile-gobject-0.5.1
Date: Wed, 23 Jul 2003 08:37:00 -0000	[thread overview]
Message-ID: <20030721175754.GA5043@lark> (raw)
In-Reply-To: <16128.21421.247153.330879@mail.wanadoo.fr>

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.

           reply	other threads:[~2003-07-23  8:37 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <16128.21421.247153.330879@mail.wanadoo.fr>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030721175754.GA5043@lark \
    --to=wingo@pobox.com \
    --cc=b-patrick@wanadoo.fr \
    --cc=guile-gtk@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).