more on scrolled window sizing ... fixes + bugs?
- From: Paul Davis <pbd op net>
- To: gtk-list gnome org
- Subject: more on scrolled window sizing ... fixes + bugs?
- Date: Wed, 17 Oct 2001 00:43:43 -0400
OK, I finally looked at this again, and started staring at the source,
as well as building a tiny C test app. Then I noticed, at the top
of gtkscrolledwindow.c:
* a scrolled window needs (for imlementing all three policy types) to
* request its width and height based on two different rationales.
* 1) the user wants the scrolled window to just fit into the space
* that it gets allocated for a specifc dimension.
* 1.1) this does not apply if the user specified a concrete value
* value for that specific dimension by either specifying usize for the
* scrolled window or for its child.
* 2) the user wants the scrolled window to take as much space up as
* is desired by the child for a specifc dimension (i.e. POLICY_NEVER).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Arg! I indeed set the policy to NEVER, but thats not at all what my
intended meaning is. Its set to NEVER because I don't want scrollbars
to be appear: the adjustments and the scrollbars for the scrolled
window are shared with other widgets (e.g. an adjacent scrolled
window). I did not mean for the child to be given as much space as it
desired.
Is there some other way to indicate "i don't want scrollbars, but i do
want to limit the size of the child"? Or should I just go ahead and
file with bugzilla, since this apparent overloading of semantics
strikes me as a serious design flaw? Or is it all fixed in GTK+
1.3/2.0 ?
Alternatively, should I just be using a viewport (or two) and creating
my own scrollbars to move the visible part of the child around?
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]