Re: signal/properties/enums/flags defs

[murrayc t-online de (Murray Cumming)]

On Wed, 2001-10-10 at 16:34, James Henstridge wrote:
> On 10 Oct 2001, Murray Cumming wrote:
> 
> > Here is a program to generate the .defs sections for signals,
> > properties, enums, and flags. You can get it by checking out the
> > gtkmm-1.3 module.
> >
> > http://cvs.gnome.org/bonsai/cvsblame.cgi?file=gtkmm-root/tools/generate_extra_defs.cc&rev=&root=/cvs/gnome
> 
> Few comments on the code.  First of all, you shouldn't need to instantiate
> the type you are working with.  In order to get the signal info, the code
> should just look something like this:
> 
>   get_signals(GType type)
>   {
>       /* we get a reference to the object class because the class_init
>        * routine (which creates the signals) isn't guaranteed to have
>        * been run yet.
>        */
>       GObjectClass *oclass = g_type_class_ref(type);
>       guint n_signals, i;
>       guint *signals = g_signal_list_ids(type, &n_signals);
> 
>       for (i = 0; i < n_signals; i++) {
>           GSignalQuery query;
> 
>           g_signal_query(signals[i], &query);
>           ... do stuff here ...
>       }
>       g_type_class_unref(oclass);
>   }
> 
> Similar can be done for get_properties routine.  This should make the
> script run a lot faster, as it doesn't have to create any object
> instances.

Done. That is simpler.

> 
> The get_type_name() function will need a bit more work.  Boxed types need
> a * on the end as well, for instance, and name of G_TYPE_STRING is
> actually "gchararray", which needs to be mapped to "gchar*".

Done.

> 
> As a stylistic note, it is probably better to use GTK_TYPE_BUTTON and
> GTK_TYPE_CONTAINER macros in the main() function rather than the
> get_type() routines directly.

Done.

> 
> >
> > And here's a sample .defs file, for GtkButton and GtkContainer. Does
> > anyone know how I can dynamically get a list of all the GTK/GDK types,
> > instead of having to hand-code gtk_button_get_type(),
> > gtk_container_get_type() etc?
> 
> Parsing the output of nm, or going through the headers are probably the
> best options.  Scanning the headers is a better idea, as it won't pick up
> private objects.

Hmm, maybe I'll play with h2defs.py

> 
> Probably the best way to structure this tool would be to put all these
> helper functions for outputing defs into a small static library, then have
> a script that scans for a list of types in a library, outputs a small
> program and links it against the helper library and the lib being scanned,
> and then runs the resulting program.

Couldn't you just use the libary from h2defs.py?

> 
> >
> > http://www.murrayc.com/temp/gtk_extra.defs
> 
> looks good.
> 
> >
> > It only does signals and properties at the moment. Does anyone know how
> > I can ask a GObject, or glib itself, for it's enums and flags?
> 
> There isn't a standard way to do this.  Again, we need to scan for the
> *_TYPE_* variables/macros in the headers.  Your get_defs() function would
> probably handle objects, enums and flags:
>   if (G_TYPE_IS_OBJECT(type))
>      get_object_defs(type)
>   else if (G_TYPE_IS_ENUM(type))
>      get_enum_defs(type)
>   else if (G_TYPE_IS_FLAGS(type))
>      get_flags_defs(type)
>   else
>      print an error message.
> 
> James.
> 
> -- 
> Email: james daa com au
> WWW:   http://www.daa.com.au/~james/
> 
> 
> 
> _______________________________________________
> language-bindings mailing list  language-bindings gnome org
> http://mail.gnome.org/mailman/listinfo/language-bindings
> 
> 
-- 
Murray Cumming
murrayc usa net
www.murrayc.com