Re: [gtk-list] Re: Interpreter requests

[Tim Janik <timj gtk org>]

On 6 Jun 1998, Marius Vollmer wrote:

> Kenneth Albanowski <kjahds@kjahds.com> writes:

> >  4. Add a bit more .defs information describing whether the contents of a
> > structure are important, the pointer to a structure, or both.
> 
> The .defs file stuff is not in the best shape it could be.  I think
> the best would be to actually remove gtk.defs from the Gtk distro and
> make sure that gtktypebuiltins is always upto date with some adhoc
> perl or whatever.
> 
> The version of gtk.defs in guile-gtk has actually evolved away from
> the gtk.defs in Gtk.  We should coordinate what we would like in the
> *.defs files (including syntax, installation locations, mechanism for
> third party widgets, etc), document it and then move it back into Gtk.

hm, regarding enums, i've just recently (two days ago) added a function
to gtk to retrive stringified enumvalues:
struct _GtkEnumValue
{
  guint  value;
  gchar *value_name;
  gchar *value_nick;
};
GtkEnumValue *gtk_enum_get_values   (GtkType      enum_type);

i'm using an awk script to generate the appropriate arrays from gtk.defs.
originally this awkscript was used in GLE and scanned through gtkenums.h,
but gtk.defs is oviously the better source since it also covers nicks
for the enum values.
we still have the problem that we need to maintain two different files
for an enum definition, that is gtkenums.h and gtk.def.
i've spend some more thought on this issue, and think we should automate
this procedure in the way that we generate a gtk-enums.def from gtkenum.h.
but this requires gtkenums.h to have an acceptable easy-to-parse format and
to also define the nick names, since they cannot automatically be generated.

this is what i came up with:

old gtkenums.h:

typedef enum
{
  GTK_ACCEL_VISIBLE             = 1 << 0,
  GTK_ACCEL_SIGNAL_VISIBLE      = 1 << 1,
  GTK_ACCEL_LOCKED              = 1 << 2,
  GTK_ACCEL_MASK                = 0x07
} GtkAccelFlags;

/* Arrow types */
typedef enum
{
  GTK_ARROW_UP,
  GTK_ARROW_DOWN,
  GTK_ARROW_LEFT,
  GTK_ARROW_RIGHT
} GtkArrowType;

old gtk.defs:
[NOTE the difference between define-enum and define-flags]

(define-flags GtkAccelFlags
  (visible GTK_ACCEL_VISIBLE)
  (signal-visible GTK_ACCEL_SIGNAL_VISIBLE)
  (locked GTK_ACCEL_LOCKED)
  (mask GTK_ACCEL_MASK))

(define-enum GtkArrowType
  (up GTK_ARROW_UP)
  (down GTK_ARROW_DOWN)
  (left GTK_ARROW_LEFT)
  (right GTK_ARROW_RIGHT))


new gtkenums.h to generate gtk-enums.defs from:

#define GTK_ENUM(enum_name)                     enum_name
#define GTK_FLAGS(enum_name)                    enum_name
#define GTK_NV(value_name, value_nick, value)   value_name = (value)
#define GTK_SV(value_name, value_nick)          value_name


typedef enum
{
  GTK_NV (GTK_ACCEL_VISIBLE,            visible,        1 << 0),
  GTK_NV (GTK_ACCEL_SIGNAL_VISIBLE,     signal-visible, 1 << 1),
  GTK_NV (GTK_ACCEL_LOCKED,             locked,         1 << 2),
  GTK_NV (GTK_ACCEL_MASK,               mask,           0x07)
} GTK_FLAGS (GtkAccelFlags);

typedef enum
{
  GTK_SV (GTK_ARROW_UP,         up),
  GTK_SV (GTK_ARROW_DOWN,       down),
  GTK_SV (GTK_ARROW_LEFT,       left),
  GTK_SV (GTK_ARROW_RIGHT,      right)
} GTK_ENUM (GtkArrowType);


i use GTK_SV as an abbreviation for "sequential value" and
GTK_NV as an abbreviation for "numbered value".


> Standard disclaimer: I do not have the time to actually work on this
> and I'm not at all happy about that fact.
> 

Not-so-standard disclaimer:
if no one complains i'll go ahead and implement this for the devel branch. ;)

> regards,
>  Marius
> 

---
ciaoTJ