Re: Review of libgnomeui's construct-time properties

[murrayc t-online de (Murray Cumming)]

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

> 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.
 
> 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.

> 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().

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.

> 
> > 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.

Yes, but I wanted to avoid that because it's so untyped.

> 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 ;)

Agreed, but this requires a major change to the aims and implementation
of libgnomeui. It's not going to happen for GNOME2 and presumably the
next stage of development is to kill libgnomeui totally in favour of
libbonobui equivalents.

> > 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.

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.

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