Re: can_change_screen property for GtkWindow

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Wed, 2 Oct 2002, Owen Taylor wrote:
> 
> >  * The "foo" "foo_set" convention for properties is already 
> >    well established, and it's easy for GUI builders to
> >    make reasonable GUI's for it.
> > 
> >    So, it made sense to me to have:
> > 
> >     can_change_screen
> >     can_change_screen_set
> >    
> >    Properties as the property interface. get/notify
> >    can_change_screen() could reasonably either be:
> > 
> >     - value set
> >     - effective value
> >   
> >    I decided to go with the value set because:
> > 
> >     - I don't know any particular reason to monitor the
> >       effective value (when this window becomes possible to
> >       move between screens, I'll move it?)
> >     - notifying the effective value is somewhat code-bloaty
> >       and expensive.
> 
> it doesn't matter much whether you consider monitoring of this special value
> a common case or not. the simple rule is that properties emit change
> notification once their value changes, regardless of the value's semantic.
> but to provide a little bit of motivation here ;), GUI builders actually need
> this to update their GUI accordingly, to record time stamps of property
> changes etc...

The invariant we have to preserve is that when the results of
g_object_get (object, "can_change_screen") change, we provide
notification.

I'm not suggesting violating this. I'm suggesting that the
result of g_object_get (object, "can_change_screen") should
not reflect the default value, because that makes notification
a pain. 

It should simply be the current value of can_change_screen
field in the object, whether or not that value is being
used.

[...]
 
> to extend on this for a bit, the primary reason i dislike the *_set property
> approach is that introducing two distinct properties which affect each others
> values when set is a bad idea in general. following the convention that one
> of them is named *_set and boolean and could thusly be figured by generic
> code like GUI builders or users is simply not enough. either everyone
> using the property system knows and commits to this convention or it's
> pretty much worthless (in terms of writing generic code for it and have
> users use object properties intuitively).
> so (despite other griefs i'm having with *_set properties), if you really
> want to follow this route in future API design, lets at least make things
> explicit (for generic code and documentation generators) by introducing:
> 
> /* returns name of a boolean property */
> const gchar* g_param_spec_get_setter (GParamSpec *client_pspec);
> 
> /* returns client pspec name from a boolean setter */
> const gchar* g_param_spec_get_client (GParamSpec *setter_pspec);
> 
> /* returns a boolean setter property for client_property */
> GParamSpec* g_param_spec_setter (const gchar    *client_property,
>                                  gboolean        default_value,
>                                  GParamSpecFlags flags);
> 
> so you introduce the abpove properties as:
> 
> object_class_add_property (class,
>                            g_param_spec_boolean ("screen_migratable",
>                                                  _("Screen Migratable"),
>                                                  _("Indicate whether a window can be moved between screen"),
>                                                  FALSE, G_PARAM_READWRITE));
> object_class_add_property (class,
>                            g_param_spec_setter ("screen_migratable",
>                                                 FALSE, G_PARAM_READWRITE));
> 
> the latter is simply a shorthand for:
>                                                  
> object_class_add_property (class,
>                            g_param_spec_boolean ("screen_migratable" "_set",
>                                                  _("Screen Migratable Set"),
>                                                  _("Toggle whether `screen_migratable' is set or unset"),
>                                                  FALSE, G_PARAM_READWRITE));
> as well as setting "screen_migratable" as client on the "screen_migratable_set"
> pspec and setting "screen_migratable_set" as setter on the "screen_migratable"
> pspec.

There is certainly something to be said for keeping your primitives
simple and adding structure by convention. 

JavaBeans takes this probably too far ... all handling of properties
is by conventionally named methods ... but the above seems like 
clutter to me.

Regards,
                                        Owen