Re: an additional argument flag

[Owen Taylor <owt1 cornell edu>]

Guillaume Laurent <glaurent@worldnet.fr> writes:

> Tim Janik <timj@gimp.org> writes:
> 
> > i just talked with jay about default construction of GtkCList on #gimp.
> 
> [...] 
> 
> > jay moved the clist initializaton stuff into a seperate function
> > gtk_clist_construct() so that at least derivation can easily be done
> 
> [...]
> 
> > this is also needed by the Gtk-- folks.
> 
> Indeed, I'm the one who asked him to do this, and I was going to
> submit a proposition to do likewise for all other "complex" widgets,
> like GtkGammaCurve, and GtkInputDialog.

Take a look at GtkInputDialog. All initialization is done in the
_init() function, and I don't see why that should be moved.

GtkWidget*
gtk_input_dialog_new (void)
{
  GtkInputDialog *inputd;

  inputd = gtk_type_new (gtk_input_dialog_get_type ());

  return GTK_WIDGET (inputd);
}

[ That should be changed to:

GtkWidget*
gtk_input_dialog_new (void)
{
  return gtk_type_new (gtk_input_dialog_get_type ());
}
]

> Note that the only reason we need this is because gtk-- plugs its own
> GtkTypeInfo in for its widgets, so we can't use all the
> gtk_<widget>_new() functions.
> 
> Therefore, either we duplicate all the "widget setup" code in each
> _new() into the gtk-- constructors (which is what we currently do,
> since it's quite tolerable for most widgets), or we get a new entry
> point in the construction chain right after the call to
> gtk_type_new().

Hmmm, some day I'm going to have to take a look at gtk-- and see
what is going on there. I get the feeling that there is some
horrible perversion of the GTK type system going on there. ;-)

Does gtk-- actually _change_ the type of the created widget. I don't
see how this is necessary, or how it can successfully be integrated
with normal GTK+ code.

What I would expect is the gtk-- heirarchy would parallel the
GTK heirarchy, and a gtk-- object would keep a pointer to
the corresponding GTK object. But something more complicated
is clearly being done. Is there a description of the design
of gtk-- anywhere? (Somebody may have emailed me some more details
earlier, but I can't find the relevant message, if so)


But be that as it may, it seems to me that everybody isn't
quite talking about the same thing here.

The problem is quite clear:

 Some widgets need to do initialization that _depends_ on 
 the parameters that are passed in. However, no parameters
 are passed to the _init() function. So this has to be
 done in the new () function. (The list of such functions
 is currently quite short though)

  - Tim doesn't like it, because he wants to do his 
    gtk_widget_new (...) thingy.

  - Tero and Guillaume don't like it, because they want want
    to do there black magic with widget types.

  - Normal people (;-) don't like it, because they can't
    derive new widgets without rewriting the new() function.

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)

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

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

Regards,
                                        Owen