Re: gobject introspection
- From: Rob Taylor <rob taylor codethink co uk>
- To: Michael Lawrence <lawremi iastate edu>
- Cc: gtk-devel-list gnome org
- Subject: Re: gobject introspection
- Date: Wed, 02 May 2007 17:39:56 +0100
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?
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]