Re: Runtime Linkage queries

[Owen Taylor <otaylor gtk org>]

Tim Janik <timj@gtk.org> writes:

> > * I like the idea. I hate the names. (Suprise, suprise... ;-)
> > 
> > The word "linkage" is very confusing to me in this context. (It make
> > me think of car parts, or of object files)
> > 
> > How about simply child_arg (Or child_attr/child_opt; Using the term "arg"
> > for widget attributes was utterly wrong; "option" would have been
> > OK, but "arg", arrrgghhhh....)
> > 
> > gtk_container_add_linkage_arg_type => gtk_container_add_child_opt_type
> > gtk_container_query_linkage_args => gtk_container_query_child_opts
> > gtk_container_linkage_setv => gtk_container_set_child_optsv
> > gtk_container_linkage_getv => gtk_container_get_child_optsv
> > 
> > gtk_container_linkage_add => gtk_container_add_with_opts
> > gtk_container_linkage_addv => gtk_container_add_with_optv
> 
> well, i think the name changes are ok, except i stil tend to use
> child_arg instead of child_opt, just because the mechanism is basically
> copied from widget_arg, and imho, we should stick to the existing naming
> convention for this mechanism, even if it was badly choosen in the first place.

Yeah. <sigh>

[...]

> > (Note that a UI builder that wants a really nice interface to
> >  containers - e.g., interfactive manipulation, probably actually needs
> >  to know more about the container, so I'm not sure that being
> >  able to sometimes guess if an addition will succeed in advance
> >  is very valuable)
> 
> it would be valueable. e.g. you chose a certain wiidget from a widget
> pallete, lets say a label. you then drag this label onto several containers.
> having the builder display wether addition to the currently selected container
> would succeed is very usefull. the builder could even climb up the widget
> hirarchy untill it finds a container suitable for the addition and display
> taht in a status window.

Consider DND'ing into a box. The nice interface is that as you
drag over the box, the UI builder changes the place in the list
of children where the child will be inserted, and shows a gap 
to provide feedback. 

This level of feedback clearly requires the builder to know exactly
what a box is. 

So while conceivably useful, the gtk_container_child_type() is
far from a panacea.

> as for the above mentioned two functions, i think since a gboolean already
> takes up 4 bytes, we could just return the child type instead of a plain
> boolean value, and thus have those two functions combined into *_child_type().
> 
> so we'd just have
> GtkType gtk_container_child_type (GtkContainer *container);
> 
> and this function will change its return value to TYPE_NONE if `container'
> is full (i.e. doesn't have any unoccupied "slots" anymore).

OK. I think it is slightly confusing overloading of two distinct
operations into one call. But it does make things easier
on the container-writer. (Since they only need to implement
one virtual function)

[...]
 
> >   This mandatory "GtkBox::padding" stuff just sucks; if lookup 
> >   was done as one would expect, it would be easy enough to 
> >   support "GtkBox::padding" as a special form to do overrides, if 
> >   the ability to reuse a inherited attributed name in a descendent
> >   class was really desired.
> 
> well, peter actually had a quite strong point in making it the way he did.
> if i implement a widget argument "GtkButton::name" which could for instance
> act similar to the already existing "GtkButton::label" argument, and later
> i decide to extend GtkWidgetClass to support "GtkWidget::name" as argument
> variant for gtk_widget_set_name(), this argument can never be used for buttons
> since a "name" argument lookup would always give me "GtkButton::name".

That's why you have overrides. When such a conflict exists, you
could use GtkWidget::name. Now, you could say that if it was the
other way around, ::name was later added to GtkButton, then it
would break existing programs. But the only time it can matter
is if a derived class adds an argument that already exists in
a base class - which I think the widget-writer can be expected
to take worry about.

[ I suppose the contrary argument is that we write:

  GTK_BUTTON(button)->child
  ^^^^^^^^^^
  gtk_container_border_width (GTK_CONTAINER (foo), 10)
  ^^^^^^^^^^^^^

 But I tend to think of this as a defect in the way OO C works
 not a feature. $foo->border_width (10) as in the Perl bindings
 or gtk-- is much nicer ]

> you can insist, that a programmer can take care about such things, but the
> way gtk is designed, every user can derive his own widgets and implement
> any widget arguments for those, thus especially arguments that a core gtk
> developer doesn't even know about. besides this, arguments were meant to be
> closely related to the c-structure field names, and in c it is perfectly valid to
> have a constructin like:
 
> struct foo
> {
>   gint  width;
> };
> 
> struct bar
> {
>   struct foo   foo_parent;
>   gint         width;
> };
> 
> thus the arguments need to support the inheritance level.

As above, allowing optional full specification will resolve
this situation, and if the derived class programmer avoids
intentionally creating such situations, existing meanings
of arguments will never change.

> ok, enough with defending the current argument implementation ;)
> 
> if people want this, i can provide a (convenience) lookup function:

[...]

Even if we don't change the registration mechanism, I think such a
mechanism should be invoked if the user gives a argument name without
a '::'. I know that Perl/GTK is already emulating this behavior. GTK+
is certainly in a better position to do it efficiently and everybody
will benefit.

Regards,
                                        Owen