Re: [gtk-list] Re: Window manager window placement and X modifiers/states

[Paul Barton-Davis <pbd op net>]

>> although i love GTK's adoption of the TeX glue+box model, the one area
>> where it falls down is in the domain of widgets that actually have to
>> be a certain size in order to work. when this size is a function of
>
>I think what's falling down here is the widgets, rather than the
>geometry model. i.e. the widgets should be able to give a more
>intelligent size_request.

agreed on the first part. this would help, but it doesn't all happen
at the time of size allocation. consider the popdown list on a combo -
it can have its strings replaced at any time, and should dynamically
resize itself to display the longest one. right now, it fails
miserably at this. just a bug ? maybe, but i see it as indicative of a
more widespread design concept.

>> the most egregious example of this is the GtkEntry widget used with a
>> GtkSpinButton. This often ends up being a completely useless size,
>> unrelated to the width necessary to display the value range of the
>> associated adjustment.
>>
>
>Here for example a simple gtk_spin_button_size_for(spinbutton, text)
>added to the API would solve the problem.

this should be totally unnecessary. the end points of the adjustment
and the "digits" setting are sufficient to determine this.

in general, however, this won't work. consider my own Gtk-- widget,
Gtk_Spinner. this uses a filter function which can be supplied by the
programmer to display the value of the "spinbutton". there is no
programmatic way to determine how wide the maximum display will be.
for instance, the adjustment may go from 1 to 12, but be displayed as
the set of strings "Jan" - "Dec". alternatively, it may be "January" -
"December". the filter could change at run time. so once again, you
can't determine this at widget creation time - the programmer who sets
the filter function would have to manually call the size function and
that function may have to request an actual resize of the widget (can
this be done ?)

this seems like a sufficiently general problem that i see little
justification for making this a per-widget-class function. there is
one problem with making it generic, however. if you try this on, say,
a SpinButton, you'll end up sizing the overall dimensions of the
displayed stuff. Sometimes, in the case of various "composite"
widgets, you need to size just one part of them.

all this points in the direction i alluded to earlier: GTK has wisely
taken an approach that generally allows for easy scaling, shrinking
and growing of windows/widgets. however, this model doesn't work well
when the size of a widget is critical for its operation, and it works
even less well when this size may need to change during the course of
the widget's lifetime.

--p