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

[Tim Janik <timj gtk org>]

On Fri, 12 Jun 1998, Damon Chaplin wrote:

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

as you stated below, this is normally taken care of through the resizing
and redrawing queues. also, at least for builders, you will either
change arguments at non time critical points, e.g. if a user modifies a
certain value on the builders gui, you can immediately change that,
or you set a certain set of arguments at widget creation time, which usually
doesn't result in performance impacts as well because the widget isn't yet
realized (a *huge* portion of the delays noticable in gtk application
originates in server round trips).

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

for one thing, resizes are queued as you said, and thus multiple argument
changes result in one resize at most. also, the resizing code tries quite
hard to avoid unneccessary reallocations where it possible. e.g. if you
queue all widgets of a window's widget tree for resizing (starting from the
leaf widgets, since widgets won't get queued for resizes if an anchestor
is already queued, you still got only one size request and allocation from
the toplevel because it sorts out the resizing lists.

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

this is about the way it works. usually the setting of a widget argument
is just an "alias" of a certain function call, e.g. gtk_frame_set_shadow_type()
and thus only introduces the overhead of the hash lookup for the argument
name.

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

basically: yes. i tried it the other way first, when i actively worked on
gubi about one year ago. even then i tried to be as generic as possible and
kinda "invented" my own widget arguments, including widget description
inheritance. but after some time i found out that this is not the best way
to create a gui builder for gtk since gtk's code changed quite frequently,
and i implemented a lot of code and workarounds in gubi that actually should
have went into gtk itself. since then i'm trying to exactly do this, putting
generic mechanisms and usefull bug fixes into gtk itself. the implementation
of the "linkage arguments", is about the last step on this road (though there
are a lot widgets left that don't support the widget arguments yet).

most interpreter bindings that have come up meanwhile, try to be generic
about the widgets as well. wrapping every single widget was feasible about
one and a half year about, we had about 40 gtk widgets at that time, but
with the extension of the widget base, wrapping became harder and harder
especially for things like radio buttons and such, and the wrapping wasn't
at all feasible for multi language support at all. even though i don't know
most of the languages that gtk already provides bindings for, i still would
like to see a gui builder for gtk someday, which will offer all the power
gtk offers to a programmer while still providing simplicity in the user
interface, plus support for any language that gtk has wrappers for.
GLE tries to fullfill this aim, but as of now, it is far behind Glade
and the state that Gubi has reached about 10 months ago.


> 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'm not sure what you mean with "placeholders" here. if you want the
ability to free-hand position widgets on a certain window, you are best
off with using certain container types only, e.g. a table or gtkfixed.

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

yep, that is what i have in mind with these functions.

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

yep, this is one of the left over areas. since this stuff is just not supported
by the widget argument system (i would have liked this ability as well, back
when this was implemented), it seems like the only ability gui builders have
is to provide extra knowledge for this...

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

nope, actually your idea about a new type is quite usefull. we just can't call
it GTK_TYPE_RANGE, since there is already a widget named this way ;)
maybe GTK_TYPE_VALUE_RANGE or something the like? this type could feature
step incrementation and page size (and of course limits...).

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

yep, the problem here is, that gtk doesn't distinguish between user added
children and children of composite widgets. this reveals real problems
with widget tree dumps for e.g. a GtkFileSelection, here the user defined
widgets are actually added to ->button_area or ->action_area, but other
container miss-uses are possible. a UI builder simply can't tell which of
those will be created by default...
i can't think of a good solution around this actually...
we could encourage composite widget writers to "tag" such widgets with a
new widget flag, but i doubt many programmers would follow this.
or we could require class_init functions that create composite children
to wrap this creation into some set_composite_creation_mode functions that
will take care of setting this flag automatically, but that wouldn't work
reliably with threading...

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

yep, for the tree dumper and signal prototype dumper i wrote, i'm already
grepping gtk headers for _get_type() functions.
actually, if you are going to provide an interface for dlopen(), a simple
text file describing the _get_type() fucntions would be sufficient, since
you can get such fucntion adresses via dlsym() calls.

> 
> 
> 

---
ciaoTJ