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

[Havoc Pennington <hp redhat com>]

Paul Barton-Davis <pbd@op.net> writes:
> 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.
> 

It's just a bug - it could queue a resize whenever you add new stuff
to the list. Option menus have a similar
bug. gtk_widget_queue_resize() should work, once the size request
method works right.

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

Well, in this case the programmer has to set the size (since the
widget can't know what the filter function does), but when you set the
size the widget could queue a resize to ask for geometry
renegotiation. 

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

I think the widgets are just broken. :-)

You do have a fundamental problem if a widget is going to be changing
sizes - interface elements "bouncing around." Here I guess you want to
be able to set a "default size" that approximates the maximum size
you're predicting.

Havoc