Re: [gtk-list] Re: Interpreter requests
- From: Tim Janik <timj gtk org>
- To: gtk-list redhat com
- cc: Kenneth Albanowski <kjahds kjahds com>, Vollmer Marius <mvo zagadka ping de>
- Subject: Re: [gtk-list] Re: Interpreter requests
- Date: Tue, 9 Jun 1998 09:02:07 +0200 (CEST)
On Sun, 7 Jun 1998, Kenneth Albanowski wrote:
> On Sun, 7 Jun 1998, Tim Janik wrote:
>
> > Not-so-standard disclaimer:
> > if no one complains i'll go ahead and implement this for the devel branch. ;)
>
> Looks good to me. The only thing I'd want to add would be a hook to type
> creation, so that I can be notified whenever a new enum is added to the
> system, giving me a chance to read its values and add it to my management
> system.
all enums are created with gtk_type_init () which is called from gtk_init();
after that you can get an enum's value by using
[struct _GtkEnumValue
{
guint value;
gchar *value_name;
gchar *value_nick;
};
]
GtkEnumValue *vals;
vals = gtk_enum_get_values (GTK_TYPE_PACK_TYPE);
/* ^ should that be gtk_type_enum_get_values(), since it's in gtktypeutils.h ? */
`vals' then holds a statically allocated NULL terminated (the `value_name'
member holds NULL and value==GTK_TYPE_INVALID==0) array of all possible
enum/flags values.
note that some of the enum values might just be aliases, and they do not need
to be in ascending order and can have gaps (especially for flags).
there is currently no correct way to know about all enum types other than
looking (parsing? ;) gtk/gtktypebuiltins.h and figure which ones are
GTK_TYPE_ENUM and GTK_TYPE_FLAGS (there are GTK_TYPE_BOXED types as well).
we had to drop the GtkType gtk_builtins[] array since it breaks binary
compatibility with the removal or addition of futher enums/flags.
but i can easily add a
GList* gtk_type_get_children (GtkType type);
/* statically allocated GList structures */
function, with whitch you can query all child types derived from
GTK_TYPE_ENUM and GTK_TYPE_FLAGS, we maintain those pointers anyways,
but they are currently only used for debug purposes (gtk_type_describe_tree()).
>
> (I've no idea whether such a dynamic system would be particularly
> efficient, but it's fun to play with, regardless.)
>
> Oh, as for using AWK code to translate the enums data into the .defs:
> don't forget, you could use _C_ code at this point...
well awk seems far easier for this since it allowes for per-pattern actions
and looks like C in most other parts ;)
>
> --
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]