Re: Review of libgnomeui's construct-time properties

[Tim Janik <timj gtk org>]

On 17 Nov 2001, Murray Cumming wrote:

> On Mon, 2001-11-12 at 22:00, Murray Cumming wrote:
> > On Mon, 2001-11-12 at 00:27, Michael Meeks wrote:
> > > 
> > > Hi Murray,
> > > 
> > > On 10 Nov 2001, Murray Cumming wrote:
> > > > I have just reviewed all the *_new functions in libgnomeui to check 
> > > > that all the widgets use construct-time properties instead of doing     
> > > > custom stuff in *_new. I have ignored deprecated widgets.
> > >   
> > >         Wow - that's great work :-)
> > > 
> > > > I'll start making a patch for this if the maintainer agrees.
> > >   
> > >         This is really good news; please do !
> > 
> > I'm having real problems with this.
> > 
> > 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.

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. and they definitely need to be readable for something like
glade, so you will want to store them as flags somewhere.

on gnome_druid_page_edge_new_with_vals(), all its values are runtime
changable already, it has set funcitons for its args.
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 discussed this with Tim Janik on gtk-devel-list
> http://lists.gnome.org/archives/gtk-devel-list/2001-November/msg00351.html
> 
> and discovered that this cannot be fixed without either
> 
> a) Adding new object struct fields whose values are only used during the
> instantiation process. For instance, this would add 6 otherwise useless
> temp_* fields to GnomeDruidPageEdge.

not just during th einstantiation process, if that were the case,
you could simply use g_object_set_qdata() btw. but these properties
_have_ to be gettable to make the widget usable besides any dumb C
code, i.e. GLE or Glade. so your actuall problem is that there'S just
way more to fix then just construct properties ;)

> or
> 
> b) Adding a great deal of code that would allow the parameters to be
> specified in any order, even though they are only actually used in the
> order of the parameters to the _new() function.
> 
> So, I can't fix it, and the existing _constuct() methods are enough for
> gtkmm. But this should still be considered a bug that others, such as
> the GLADE developers, might care about.
> 
> > 
> > 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.

> 
> -- 
> Murray Cumming
> murrayc usa net
> www.murrayc.com
> 

---
ciaoTJ