Re: [gtk-list] Re: Runtime Linkage queries

[Tim Janik <timj gtk org>]

On 12 Jun 1998, Owen Taylor wrote:

> 
> > On Fri, 12 Jun 1998, Tim Janik wrote:
> > 
> > > hi everyone,
> > > 
> > > user interface builders usually let you create complete guis through
> > > creating and placing widgets/containers in other containers.
> > > gtk implements a mechanism to query/set widget specific arguments to
> > > control widget specific behaviour, but does not (yet) support a way
> > > for runtime settings/adjustments of the way a container links in a
> > > child.
> > > i therefore would like the following things to be implemented:
> > > 
> > > - a way to query a container about the expected type of child
> > > - a way to query the supported linkage arguments of a container
> > > - a way to set these linkage arguments.
> 
> [...]
> 
> > > i'm curious about people's comments, especially damon's ;)
> 
> Here are my comments:
> 
> * 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.

> 
> * gtk_container_next_child_slot
> 
> This name is OK. I'm a little uncertain about the concept, though;
> 
>  - It implies that there is a linear ordering of the slots. 
>    (Not true for the table)
>  
>  - The interface provides a false sense that the type of the child
>    could change during the call; but in general, since you don't
>    know where you are adding without the options (i.e., there is
>    no linear ordering) this won't work.

nope, i didn't mean to imply linear ordering for this.

> The simplest might be just to change gtk_container_add () to
> return a gboolean indicating whether adding the container succeeded.
> (This should be backwards compatible with applications, though not
>  with widgets.) Note that adding a child can fail even if next_slot
> returns true:
> 
>  gtk_container_add_child_with_opts (GTK_CONTAINER (paned), widget1,
>                                     "side", 1);
>  gtk_container_add_child_with_opts (GTK_CONTAINER (paned), widget2,
>                                     "side", 1);

in this case, the child would still be added to "GtkPaned::side" (2),
(since the catuall child addition is the *main* action for this function).
the function would just fail in fullfilling the "GtkPaned::side" (1)
request.

> Less foolproof, but more amenable to UI builders is to, split the
> functionality into the two pieces that it is:
> 
>  gboolean gtk_container_can_add (GtkContainer *container);
>  GtkType gtk_container_child_type (GtkContainer *container);
> 
> (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.
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).

> /* this function is similar to gtk_object_add_arg_type */
> void    gtk_container_add_linkage_arg_type (const gchar       *arg_name,
>                                             GtkType            arg_type,
>                                             guint              arg_flags,
>                                             guint              arg_id);
> 
> * Hmmm, it strikes me that the argument system was mis-designed in
>   this respect, as well as misnamed. It should have worked like
>   signals:
> 
>   void	gtk_object_add_arg_type	(GtkObjectClass *klass,
>                                  const gchar	*arg_name,
> 				 GtkType	arg_type,
> 				 guint		arg_flags,
> 				 guint		arg_id);
> 
> 
>   void  gtk_container_child_add_opt_type (GtkContainerClass *klass,
> 				          const gchar       *arg_name,
>                                           GtkType            arg_type,
>                                           guint              arg_flags,
>                                           guint              arg_id);
> 
>   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".
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.

ok, enough with defending the current argument implementation ;)

if people want this, i can provide a (convenience) lookup function:

gchar* gtk_object_complete_arg_name (GtkType object_type,
                                     gchar  *arg_name);

this function will return g_new()ed strings which complete the class
part of the argument name:

gtk_object_complete_arg_name(GTK_TYPE_LABEL, "label") = "GtkLabel::label"
gtk_object_complete_arg_name(GTK_TYPE_ACCEL_LABEL, "label") = "GtkLabel::label"
gtk_object_complete_arg_name(GTK_TYPE_BUTTON, "label") = "GtkButton::label"
gtk_object_complete_arg_name(GTK_TYPE_HBOX, "label") = ""
gtk_object_complete_arg_name(GTK_TYPE_SEPARATOR, "signal") = "GtkObject::signal"

or maybe even
GtkType gtk_object_complete_arg_name GtkType object_type, gchar *arg_name)

which would just return the literal type of the class that introduced the
specified arg name, and one could contiue the lookup with invoking this
function again for gtk_type_parent(returned_type). (but people would
need to concatenate the arg names on their own then, e.g. via

if (GTK_FUNDAMENTAL_TYPE (returned_type) == GTK_TYPE_OBEJCT)
  name = g_strconcat (gtk_type_name (returned_type), "::", arg_name, NULL);
else
  {
    name = NULL;
    /* lookup failed for all classes */
  }

> (No offense to Peter or Tim intended. I think the argument system
>  may have suffered from being half-implemented initially, then
>  being picked up and extended later)
> 
> Regards,
>                                         Owen
> 

---
ciaoTJ