Re: [gtkmm] A small doc question



>Note that I said "try to avoid" and "unless it's absolutely necessary". 
>I can certainly imagine cases where it is necessary, and I used it
>myself a few times too.

my point was really that in *any* case where you have a bunch of
different strings to display at various times but you want the size of
the display widget to stay constant *and* large enough for the longest
string, then container layouts are never enough.

>But with regards to your example:  I have a non-editable Gtk::Entry in
>one of my apps as well and don't see the problem you described.  The
>entry is a preview area and its text changes quite often.  Neither does
>it shrink when the text is short, nor does it expand when the text
>doesn't fit into the entry.
>
>This could be a fix in GTK+ 2.0, but actually I've never seen the
>behaviour you described.

well, ok, entries don't resize, but buttons+labels do. so do event
boxes+labels. i'm just misremembering. also, the fact that entries
don't resize is itself a problem, because if the initial size is too
small for the text, its pretty useless.

not only that, but GTK+ still doesn't seem to have a simple way to say
"make this widget big enough to display this particular text". at some
point, karl or murray added my gtk+ 1.2-based utility function to the
codebase but i suspect its been dropped for gtkmm2. it might be rather
different with pango etc. as well, though i'd expect
gdk_string_extents() to still exist and work.

--p



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]