Re: G_PARAM_BUILDABLE

[Tim Janik <timj gtk org>]

On 26 Jun 2001, Havoc Pennington wrote:

> 
> Hi,
> 
> I think we should really add the "buildable" flag to param specs.
> 
> Tim has argued against this in the past on the grounds that once we
> start adding flags to GLib, we'll get a lot of "flag creep" and have
> to add more. However, I think the case for buildable is pretty strong,
> and most other object systems have this flag for properties. It's
> certainly a general-purpose flag, when you consider that writing a
> generic GUI builder is one of the primary goals of GParamSpec.

well, for BSE (and that's where GParamSpec originally steems from),
i have/use
1) 0x00ff bits from GParamFlags for read/write/construct etc.
2) 0x0f00 bits for conceptual flags, i.e. BSE_PARAM_SERVE_GUI and
   BSE_PARAM_SERVE_STORAGE. _GUI flagged properties of the model are
   present in generic view/controller builds for users to edit.
   _STORAGE properties are the ones used for serialization/deserialization
   of the model. the benefit of this destinction are property aliases
   ala:
   struct _MyObject { float volume_factor; /* 0..1 */ }
   bse_param_spec_float ("volume_f", "Master [float]", NULL,
                         0, MAX_VOL_FACTOR, DFL_VOL_FACTOR,
                         BSE_PARAM_STORAGE));
   bse_param_spec_float ("volume_dB", "Master [dB]", NULL,
                         MIN_VOL_dB, MAX_VOL_dB, DFL_VOL_dB,
                         BSE_PARAM_GUI | BSE_PARAM_HINT_DIAL));
   bse_param_spec_uint ("volume_perc", "Master [%]", NULL,
                        0, 100, DFL_VOL_PERC,
                        BSE_PARAM_GUI | BSE_PARAM_HINT_DIAL));
   the property setters/getters for volume_f, volume_dB, volume_perc all
   operate on the same float volume_factor; field, but just volume_dB
   and volume_perc are presented at the GUI and only volume_f is
   getting serialized.
   so conceptually, i consider BSE_PARAM_STORAGE to reside at the same
   level as BSE_PARAM_SERVE_GUI.
3) 0xff0000 bits for GUI generation hints (e.g. HINT_SCALE, HINT_RADIO,
   etc...)

for gtk, things are a bit different, for one, we provide no means to
support serialization in gtk proper, for another, properties are not
solely nitroduced for builder apps but are used for a very convenient
C interface as well.
in reality, about 95% percent of gtk's properties will/should be used
in GUI builders.
so i see two possibilities:

a) reserve 0x00f00 bits of GParamFlags for GLib (as well as the already
   reserved lower byte 0x0ff) and introduce G_PARAM_GUI and G_PARAM_STORAGE
   (alternatively, G_PARAM_CVIEW (controller/view) for the former and
   G_PARAM_SERIALIZE for the latter).
   this means we'll have to add G_PARAM_GUI to 95% of existing gtk properties.
b) reserve 0x00f00 bits of GtkParamFlags in Gtk+ namespace solely, then we're
   able to introduce flags and use them only for Gtk. however, we can have
   GTK_PARAM_DEPRECATED and/or GTK_PARAM_NON_BUILDABLE and only need to
   touch 5% of existing gtk properties.

> 
> Havoc
> 

---
ciaoTJ