Re: Review of libgnomeui's construct-time properties

[Tim Janik <timj gtk org>]

On 18 Nov 2001, Murray Cumming wrote:

> On Sun, 2001-11-18 at 02:23, Tim Janik wrote:

> > i'm confused, are we talking about CVS HEAD libgnomeui
> > libgnomeui/gnome-appbar.h:gnome_appbar_new() that reads:
> > 
> > GtkWidget* gnome_appbar_new             (gboolean has_progress, 
> >                                          gboolean has_status,
> >                                          GnomePreferencesType interactivity);
> > ?
> > 
> > has_progress and has_status look a LOT like they should be runtime
> > changable
> 
> Yes, but the problem is that they determine whether widgets will be
> constructed and packed into a container. I don't know how to
> retroactively insert a widget at a certain position later. Also, the
> interactivity parameter determines whether certain widgets are
> constructed, and how they are packed, which complicates things a lot. 
> 
> While it would be nice to change this stuff at runtime, nobody is asking
> for it because libgnomeui was never intended to be that flexible. .

you actually want that flexibility if you start using these things
in a GUI builder. there you first pack stuff together, and then
configure it, add spacing here, disable status display there etc.

> Certain objects do need more than one parameter to construct them
> validly. I think that this should fundamentally be possible, as it is in
> other object-orientated systems such as C++ and Java.

with our property system you get as much construction arguments
as you flag properties with either CONSTRUCT_ONLY or just
CONSTRUCT.
in this case you shouldn't use construct properties at all though,
just use normal properties and make stuff configurable.
widgets don't need to be unpacked, there's widget_show and widget_hide.

> This is more visible in libgnomeui than gtk+ because libgnomeui tends to
> have higher-level, composite, utility widgets

nope, the properties i saw don't need to be construct props at
all. they are just normal things you need to be able to configure
and change on a widget, and the new() variant is kind enough to
take those as parameters.

> > and they definitely need to be readable for something like
> > glade, so you will want to store them as flags somewhere.
> 
> How do you determine whether must be a readable property? Does Glade
> need all construction properties to be readable? Maybe we should have
> some rules about this stuff.

there's a very simple rule, ever property should be readable as well,
a builder can't make any use of it if it's not able to read the values
out.

> > on gnome_druid_page_edge_new_with_vals(), all its values are runtime
> > changable already, it has set funcitons for its args.
> 
> I do not know whether these things can really be set again after
> construction. If that functionality hasn't been used yet, then I suspect
> that the specific _construct() function is still needed first to make
> that possible.

eh? there are setters for these things, so you can set them
at any time. exporting a _construct() function in this case is bogus,
you only need construct props for things that _must_ be known at
object creation time and can not in any way change later on.

most things alterable on widgets are normal properties though,
and many _new() function still take thpose properties for convenience,
that does _not_ make them construct properties though, this is a
C convenience issue that should not be mapped into language bindings
or the property swystem.

> > that they are not gettable is API misdesign, things like glade need
> > to be able to query all this stuff.
> > 
> > on the argument order, there's absolutely no constrain here:
> > you add these arguments as normal properties to the widget,
> > they don't even need to be construct properties. then in your
> > GObjectCLass.constructor() implementation, you call
> > gnome_druid_page_edge_construct() (which should be a private
> > function) with the arguments in order, right after chaining
> > to your parent class constructor.
> 
> I thought that we would only use the constructor() if they were
> construct-only properties which would set temporary struct fields for
> use in the constructor(). If they are real properties which can be set
> at any time, then surely we wouldn't need the constructor().

yes, and in these cases you don't even need a constructor since
all things are runtime changable.
however, i was adressing the more general point you raised about
order of construct properties, which is not a problem at all with
the property system.

> This argument-order thing was a silly notion based on the idea that we
> could turn these into properties that would work if set in a certain
> documented order, but that would meltdown if used in any other order. I
> thought that changing the order of parameters to the _new() function
> would kinda document this. Now forget this paragraph.

yeah, there's not any guarantee the property system gives you on
order of construct properties, in fact, you need to assume they come
in randomly ordered. which ois ok though, since you can still handle
things after all construct properties got applied, by overiding
GObject.constructor.

> > > > 2.
> > > > Some widgets, such as GnomeFileEntry, and GnomeIconEntry already use the
> > > > deprecated gtk args system for similar stuff. Maybe I should convert
> > > > these to use the properties system instead. But I'm worried that I won't
> > > > know about other code that uses the old args system until we get runtime
> > > > bug reports later.
> > > 
> > > I am still waiting for a response about these deprecated args.
> > 
> > erm, i'm not sure what exactly you mean here, but are you assuming that the
> > old argument system doesn't work with 2.0 anymore? there's sufficient compat
> > code in place to get the old arg system going on top of the new property
> > stuff, it just produces poor property specifications for Glade and friends.
> 
> I didn't know that the old args system and the new properties system
> work together. So maybe it's safe to convert them to properties.
> 
> I did think that libgnomeui probably shouldn't use deprecated
> interfaces, and I'd like some libgnomeui maintainer to say whether they
> should be converted. Of course, a week later, it's too late now.

they should be converted, yes.
and converting from the arg system to the property system is not
an API issue, so i don't see why its too late...

---
ciaoTJ