Re: [gtk-list] Re: an additional argument flag

[Tim Janik <timj gimp org>]

On 21 Feb 1998, Owen Taylor wrote:

> But I'm not sure what people are proposing to do about it.
> 
>  ??? Tim's solution: mark all mandatory arguments of the widget
>      with a flag, then have a special "construct" signal that
>      does the argument-dependent initialization _after_
>      the the mandatory arguments have been set. ??? (This is
>      a bit ugly for people who don't want to do a query_args()
>      type dynamic thing, though such people should be able
>      to look a the source code and figure out there own way
>      of setting the mandatory arguments)

an extra signal emission isn't neccessary, since the widgets setup
code (e.g. gtk_clist_construct ()) can be called from the widgets
*_set_arg function once the mandatory arguments are all set.

>  ??? gtk-- solution: Give each widget that needs it, 
>      a special (non-virtual) _construct() function that
>      takes the necessary arguments ??? (This is not going to
>      solves Tim's problem.

this goes along with my problem, example:

GtkClist requires the number of columns provided at creation time,
hence the constructor:

GtkWidget *gtk_clist_new (gint columns);

now jay moved the code that depends on the number of columns into
a special contruct function:

void gtk_clist_construct (GtkCList * clist,
                          gint columns,
                          gchar * titles[]);

which resulted into a much simpler gtk_clist_new () function:
GtkWidget *
gtk_clist_new (gint columns)
{
  GtkCList *clist;

  if (columns < 1)
    return NULL;

  clist = gtk_type_new (gtk_clist_get_type ());
  gtk_clist_construct (clist, columns, NULL);
  return GTK_WIDGET (clist);
}

as i have shown in another mail, i just want the functionality of
gtk_clist_construct () to be exported to the gtk_widget_set () interface
as mandatory arguments.

now this solves my problem, which is to know what arguments are mandatory.
this also solves the Gtk-- problem since they can call gtk_clist_construct
and don't need to spend time on cut/paste orgies, and get around to maintain
code that actually belongs into gtk+.
also this eases inheritance since gtk_clist_construct can be called in
a derived widgets *_init function, and the above point on code maintainance
is also taken care of.


> Maybe people can explain more about what they want to do
> for my benefit.

i wrote another mail
Subject: Gtk+ Generic Building (and some history ;)
which describes my personal reasonings. (though i omitted the part about
querying the available children slots of a container which will most likely
introduce another signal. i'll probably write about this during the
next week ;).

> 
> Regards,
>                                         Owen

---
ciaoTJ