Re: gobject introspection



Michael Lawrence wrote:
> On 5/2/07, Rob Taylor <rob taylor codethink co uk> wrote:
>>
>> Michael Lawrence wrote:
>> > On 5/2/07, Rob Taylor <rob taylor codethink co uk> 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
>> >>
>> >
>>
>>
> 




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