Re: Runtime Linkage queries

[Owen Taylor <otaylor gtk org>]

> 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


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

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

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)

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

(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