Re: [gtkmm] A small doc question
- From: Paul Davis <pbd op net>
- To: Daniel Elstner <daniel elstner gmx net>
- Cc: Jussi Pakkanen <jpakkane yahoo com>, gtkmm-list gnome org
- Subject: Re: [gtkmm] A small doc question
- Date: Wed, 16 Oct 2002 21:31:45 -0400
>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]