Re: signal/properties/enums/flags defs
- From: James Henstridge <james daa com au>
- To: <murrayc usa net>
- Cc: "language-bindings gnome org" <language-bindings gnome org>
- Subject: Re: signal/properties/enums/flags defs
- Date: Wed, 10 Oct 2001 22:34:36 +0800 (WST)
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.
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*".
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.
>
> 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.
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.
>
> 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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]