Re: Review of libgnomeui's construct-time properties

[James Henstridge <james daa com au>]

Murray Cumming wrote:

> On Sun, 2001-11-18 at 02:23, Tim Janik wrote:
>
> > > > 1.
> > > > The construct-time properties for some widgets such as GnomeAppBar and
> > > > GnomeDruidPageEdge would have to be set in exactly the correct order.
> > > > Even if this was acceptable, I'd have to change the order of the
> > > > parameters to some _new() functions to show this.
>
> Please ignore these earlier, less informed comments of mine..
>
>
> > 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. .
>
> 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.
>
> This is more visible in libgnomeui than gtk+ because libgnomeui tends to
> have higher-level, composite, utility widgets
Why not just create the widgets unconditionally, and show/hide them when 
the appropriate properties are set?  Or would this cause more problems?

James.