Michael Lawrence wrote: > On 5/2/07, Rob Taylor <[EMAIL PROTECTED]> wrote: >> >> Michael Lawrence wrote: >> > On 5/2/07, Rob Taylor <[EMAIL PROTECTED]> wrote: >> >> >> >> Damon Chaplin wrote: >> >> > On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: >> >> >> Michael Lawrence wrote: >> >> > >> >> >>> I made some suggestions along those lines a while ago on the >> >> GtkDocFuture >> >> >>> page: http://live.gnome.org/DocumentationProject/GtkDocFuture. >> >> It's at >> >> the >> >> >>> bottom of the page. >> >> > >> >> > I'm not sure I like the idea of the gtk-doc comments containing >> extra >> >> > tags for return values and arguments. It could get pretty messy. >> >> >> >> Agreed. >> >> >> >> > >> >> >> Yeah, hmm, my take is that the introspection data should live in >> the >> >> >> code, and gtk-doc should pick these up for the docs (just like >> signals >> >> >> and object hierarchy). >> > >> > >> > Well, I think we both agree that there needs to be an API somewhere for >> > storing the metadata in memory. I'm looking forward to your prototype. >> It >> > would be great if the API were integrated with GClosure; that way >> language >> > bindings could leverage existing marshaling code to support invoking >> > methods >> > introduced by the language. >> >> I was planning on using ffi, so we can lose all the marshalling code. >> How does that sound to you? > > > I guess using libffi closures would work, but GClosure is definitely better > documented. Would libffi be bundled with GLib given that there's no current > release?
I've been using the libffi that's part of gcc. At least on debian/ubuntu this is installable as a separate package. As python 2.5 ctypes depend on libffi, I'm not expecting it to be a huge issue platform-wise. I don't expect the interface for bindings maintainers will require any knowledge of ffi. Anyhow, enough talk, I need to actually finish the work before discussing any more :) > Relatedly, I'd like to see pygobject's g_cclosure_marshal_generic_ffi in >> glib proper. >> >> > I'll be able to tell more after hashing out my >> >> >> prototype. One point I'm interested in from that POV: are there any >> >> >> plans for gtk-doc to document signals/properties on interfaces? >> (e.g >> . >> >> by >> >> >> instantiating objects pretending to implement them?) >> >> > >> >> > gtk-doc documents signals/properties on interfaces already. >> >> > >> >> >> >> Ah good! I had the impression it didn't ATM :) >> >> >> >> Thanks, >> >> Rob Taylor >> >> >> > >> >> > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list