Fri, 7 Nov 2003 17:36:18 +0100
> From: Havoc Pennington [mailto:firstname.lastname@example.org]
> > I'm in no rush personally, but I'll try to put some crap in cvs so
> > that others can look at it. Would you like me to put my crap in the
> > freedesktop cvs or GNOME's?
> It's up to you, if the bindings are generic C++ the
> freedesktop cvs probably makes sense.
Yes, I'm not planning any dependencies on glibmm or libsigc++, for instance.
Can you fix me up with a cvs account? However, I'm not likely to put
anything in cvs for a couple of weeks.
> > > By code generation I mean either IDL -> sourcecode (CORBA
> model), or
> > > sourcecode -> IDL -> typelib (moc/DCOP model). Or IDL ->
> > > typelib perhaps, if you want to make people do more typing.
> > Thanks for the tip. I didn't realise that the glib bindings were
> > generated.
> They aren't, but the idea is that application code would
> (partially) be.
Oh, I see. I've tried not to think about the IDL issue, because
code-generation is so unpleasant even with CORBA.
I'm personally interested in dbus for very simple message passing and
notification. So if I don't do the IDL stuff then hopefully someone else can
do it on top of my bindings.
> Specifically what the generator would create
> is a metadata blob in the form of a static variable. You then
> #include this blob in your GObject subclass implementation
> and it allows the glib bindings to type-safely dynamically
> marshal methods on your object when dbus messages are received.
> This isn't implemented yet, though. It's the way the DCOP/Qt
> stuff works.
> There are some messages in the archives discussing this more IIRC.
> > I'll be trying to wrap the lower level API as well as creating a
> > higher level API like in the python bindings.
> The lower level API is designed almost purely for the use of
> wrapping the main loop glue (DBusWatch,
> connection_set_watch_functions) and the object data
> set/getters is probably pointless bloat/confusion in your binding API.