guile-gtk-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Roadmap to 2.8 platform bindings


From: Andreas Rottmann
Subject: Re: Roadmap to 2.8 platform bindings
Date: Tue, 11 May 2004 11:56:28 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Andy Wingo <address@hidden> writes:

> Yo,
>
>      1. The module split. I assume rotty's on this and it will happen
>         magically ;)
>
This is mostly done and working now. I wrote a mail about that, but it
seems that got lost, I'll resend it; the relevant part in this context
is:

tla get address@hidden/dists--dev--0 guile-gnome
cd guile-gnome
tla build-config -r configs/gnu.org/dev
cd src
./autogen.sh --noconfigure
mkdir ../_build && cd ../_build
../src/configure
make

>      3. Define the public namespace to be (gnome FOO): (gnome
>         source-view), (gnome pango), etc. Honest sub-modules can exist,
>         for example (gnome extra repl), (gnome gobject types), but I
>         don't like having (gnome gtk glade); it should be (gnome glade).
>         Where we put the g-wrapped libs is not important for the
>         purposes of the platform bindings, because they're private to
>         the bindings generator, which we're not declaring stable.
>
This is already solved in the split modules; there is a (gnome gw FOO)
and a (gnome FOO) namespace; the latter should just contain hand-coded
stuff.

>      4. We need to go through the gobject API with a fine-toothed comb
>         to see if there's anything that could bite us later, or that
>         needs to be reimplemented. I think that breaking
>         primitives/non-primitives into separate modules (object,
>         parameters, enums/flags, gtype, typed values) will force us to
>         do this.
>      5. We need to briefly visit the other APIs to see if there are any
>         problems. It would be useful to identify all types that are
>         inputs to functions but are opaque and can't be produced by
>         scheme, and then disable those functions because they can't
>         work. I'm thinking of all those int* parameters in
>         libgnomecanvas. What a pain. An intelligent g-wrap could help
>         here. 
>
Assuming those "gint*" are pure output parameters, this can already be
solved with G-Wrap TNG; the following is from glib-spec.scm:

  (add-type-rule! ws '(("gint*" "*")) '(int out))

This adds a rule that all parameters of type "gint*" (regardless of
their name; "*" is a globbing pattern) to be "int" output
parameters. The return value and output parameters are then delivered
with (values ...) to the caller (if there are more than 1 values to be
delivered).

The other thing that needs to implemented in G-Wrap proper is combined
arguments (e.g. pointer + int = array).

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]