Roadmap to 2.8 platform bindings

[Andy Wingo]

Yo,

If we want to make it in for gnome 2.8 platform bindings, we have to
move. Especially scary is that we don't have but one or two apps, and
this would put our API as completely stable (modulo additions) until
gnome 3, which could be a while. Something to think about. Perhaps it's
not possible yet. In any case, we should join up with their schedule,
and for christ's sake get some tarballs out.

     I. I'll say it at the top while lurkers are still reading: we could
        really use some help, especially working up some test cases.
        There's the beginnings of guile-gtk-demo in the source tree, but
        it only has a couple examples. Translate from C, or easier from
        python, and just chuck the new examples in the demos/ directory.
        Fun, instructive, easy, and good for guile-gnome.

But, assuming we do run along with them, officially or not, there are
some things we need to work on:

     1. The module split. I assume rotty's on this and it will happen
        magically ;)
     2. Fix the convoluted primitives/non-primitives distinction for the
        base object wrappers.
     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.
     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. This issue is, a lacking function can be added later, but
        a broken function can't be fixed. Perhaps this isn't such an
        issue with functions whose arguments are impossible to make, but
        more with functions that would take different arguments in a
        natural scheme wrapping.
     6. Then there's the problem of custom constructors for certain
        objects. If any object needs a custom constructor (the message
        box is one example), it has to be fixed now, I think.

Dunno, just listing ideas off the top of my head. Following is an old
email regarding the chunking up of (gnome gobject). All thoughts are
welcome.

Cheers,

Wingo.

On Wed, 2004-02-25 at 22:05, Andy Wingo wrote:
> On Wed, 2004-02-11 at 20:06, Andreas Rottmann wrote:
> > > Interpreted languages don't need types and classes; the classes are the
> > > types. This realization could lead to a rethinking of our confused
> > > primitives/nonprimitives distinction. Dunno, though.
> > >
> > Yes, I always wondered what is so primitive about our primitives
> 
> Dunno. It's a holdover from 0.2.0. It does indeed need rethinking.
> 
> To me, the logical distinction is not primitives/goops, it's more along
> the lines of functionality. If you look at the header for gtype.h, it
> says:
> 
> /* GObject - GLib Type, Object, Parameter and Signal Library */
> 
> My categories would be:
> 
> Things to hide from a typical session:
> 1) GType -- the base type system, only dealing with GTypes
> 2) Typed values: GValue, to and from scheme
> 
> Things to export:
> 1) GObject: its signals, properties, ancestry, etc. But never really
> dealing in GTypes, except maybe for gtype-instance->type. Maybe.
> 2) Parameters: Necessary for deriving new types with properties. Also
> necessary for introspecting properties.
> 3) Closures
> 4) Enums and flags: genum->symbol, gflags->value-list, etc.
> 
> All of these are essentially separate modules. There are some points
> where they touch (parameters and signals touch values, for instance, and
> a GObject can be stored in a GValue), but it might be good to separate
> them into (gnome gobject value) and (gnome gobject type) or something.
> Don't know! Also, you might need a separate module to set up the GOOPS
> class hierarchy. Parts specific to, say, GObject can be implemented in
> the GObject file itself.
> 
> Well, that's enough blathering for one email. What do you think? Do we
> care? I would like to think that this is our last major reshuffle,
> besides maybe module locations.
-- 
Andy Wingo <address@hidden>