RE: [gtk-list] Runtime Linkage queries

["Damon Chaplin" <DAChaplin email msn com>]

Tim Janik wrote:
> 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.

Yes, that would be handy. The functions looked fine to me, though
I preferred 'child_arg' and Owen's functions:

 gboolean gtk_container_can_add (GtkContainer *container);
 GtkType gtk_container_child_type (GtkContainer *container);


I do have one slight concern about the whole Get/SetArgs mechanism.
The problem occurs if you have a widget with several important Args,
(i.e. if any of these Args are changed a lot of computation is
needed to update the widget).

If you use gtk_widget_setv() etc. to update these properties, the Args
are updated one at a time, so this computation will be performed several
times. (e.g. In the case of containers, it may mean going through all the
resizing calculations when each Arg is set - since resizes are queued in
GTK this is probably avoided, but you get the idea.)

Am I right to be concerned about this? Or do you expect all widgets to
only perform minor computations in set_arg and simply set a flag such as
'need_recomputation' so that when the widget is next displayed it does all
the computation. I suppose this would be OK, as long as widget
implementors know this.


I think it would be very difficult to write a GUI builder that had no
built-in knowledge of specific GTK containers - i.e. all code is generic.
Is that what you are aiming at?

Especially something like Glade, which uses placeholders to help layout
widgets. How would it know how to set up a table full of placeholders?
And to remove/resize them as widgets are added/deleted?

I doubt that too many containers will be used which aren't standard GTK
widgets, and for these we could probably get by with the generic code.
- Glade would have to support dragging widgets from the palette onto a
container, where it will get added with a plain gtk_container_add().
The child args can then be edited using your new functions,
which should be OK.

I can't see any problem (but then I missed a stupid one in Glade
yesterday so don't take too much notice of me!)

Damon

PS. The enums thing you were discussing would seem to solve one of the
other problems preventing a generic GUI builder. I think there are only a
few left:

1. Arg ranges - Args with numeric values may only have a limited valid
   range. How can a GUI builder determine this? I suppose it could get by
   without them, but it wouldn't be able to use spinbuttons for floats,
   since it would have no idea of what to use for the increments.

   Idea: how about another GTK type - a float/double with a range of 0 to 1?
   I've checked the Glade code and this is the only time spinbuttons are
useful
   for floats anyway. (That's probably asking too much just so I can use
   a spinbutton in Glade!)

2. Widgets which create several child widgets - the buttons of dialog boxes,
   the titles of clists, notebook tab labels & menus. How does a GUI builder
   know which widgets' properties can be changed, and how does it refer to
   these children when loading & saving UI description files? - I've added
   some code to Glade to do this, but I'm not sure how well it will work,
   and its not generic.

3. Dynamic loading - A GUI builder would need to be able to load libraries
of
   external widgets, and be able to determine the widgets available.
   (All it needs is a standardized init() function in every widget library
   which initialises the widgets (with gtk_<widget name>_get_type()) and
   returns the type IDs of all the widgets in the library.)