Re: GnomePixmap vs. the old gnome_create_* functionality
- From: Vollmer Marius <mvo zagadka ping de>
- To: tromey cygnus com
- Cc: Gnome Mailing List <gnome-list gnome org>
- Subject: Re: GnomePixmap vs. the old gnome_create_* functionality
- Date: 04 Mar 1998 10:43:39 +0100
Tom Tromey <tromey@creche.cygnus.com> writes:
> Quartic> I am thinking that all the Gnome widgets should be put into
> Quartic> the .defs file for the guile-gnome part...
>
> I looked at this the other night, when I wrote gnome.defs.
>
> The problem is that many Gnome widgets use capabilities that can't be
> expressed in the .defs file. For instance neither arrays of strings
> nor GLists can be handled.
That's right. Another important thing missing is `pass by reference'
parameters.
But now that people have more experience with CORBA: Is it possible to
use CORBA for C<->Scheme interfaces? Without rewriting the existing C
API of gtk?.
> Too bad the gtk.defs/gen-typeinfo rewrite disappeared.
Hmm, I'm not aware of any actual rewrite. There were some more or
less concrete ideas floating around but none of them really
materialized, as far as I know. I can probably dig them out of my
mail archives, but the larger part of it sits on a dial-up box that is
out of my reach right now. But I think Tim posted the results to the
gtk-list.
> It might be possible to add the missing features without a huge
> rewrite. I haven't investigated that, either.
It shouldn't be too bad. Arrays can certainly be handled, we just
have to extend gen-typeinfo's idea of types. For example
`(counted-array string)' could mean a char**,int pair where the int
holds the number of elements of the array. `(zero-terminated-array
strings)' could mean a single char**, where the last element of the
array is NULL. Etc.
Things are more complicated with GLists. The elements of a GList are
untyped void* pointers, but we need to attach types to them. Very
likely, there are no heterogenous lists in gtk or gnome, so we can
attach a single type to all list elements. `(dlist GtkListItem)',
`(slist GtkRadioButton)'.
And we must be aware that these arrays and lists do not retain their
identity when they travel thru interpreter land. That is
(gtk-radio-button-new (gtk-radio-button-group rb))
will not work right, most likely. Oh no, I just checked the source
and it seems that it *will* work. Nice!
Inout parameters are difficult for Guile because we don't yet have a
way to return multiple values. But R5RS is out now (I haven't had a
look), and we can just implement what they say about multiple return
values.
Ok, and then there is the problem with memory management. Who owns
the array/list? But that should be solvable, too.
Just some random thoughts...
Marius
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]