GTK: ScrolledWindow wants infinite space, how to limit it?

2
votes

I create a large TreeView within a GTK ScrolledWindow within a hpaned within a notebook within the toplevel window (and toplevel window has a limited default size).

When I create a ScrolledWindow with TreeView within, it gets allocated as much space as TreeView takes (which is greater than the screen size) and my toplevel window is resized to infinity. How do I limit ScrolledWindow's allocation or its Viewport size? What's the mechanism that determines its default size?

1
gtkpygtk
Please show some code, details can really matter with GTK+. – unwind
@unwind You're right. A minute please, I'll try to throw away everything irrelevant from the example. – Boris Burkov

1 Answers

1
votes

Question seems to be solved. The size requisition of ScrolledWindow depends on its POLICY (in the respective direction) and is equal to requisition of child widget (treeview) if POLICY_NEVER is set, see gtkscrolledwindow.c:

scrolled window policy and size requisition handling:

gtk size requisition works as follows:

  • a widget upon size-request reports the width and height that it finds to be best suited to isplay its contents, including children.
  • the width and/or height reported from a widget upon size requisition may be overidden by the user by specifying a width and/or height other than 0 through gtk_widget_set_usize(). 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).

also, kinda obvious:

3) a user would certainly not have choosen a scrolled window as a container for the child, if the resulting allocation takes up more space than the child would have allocated without the scrolled window.

conclusions:

A) from 1) follows: the scrolled window shouldn't request more space for a specifc dimension than is required at minimum.

B) from 1.1) follows: the requisition may be overidden by usize of the scrolled window (done automatically) or by usize of the child (needs to be checked).

C) from 2) follows: for POLICY_NEVER, the scrolled window simply reports the child's dimension.

D) from 3) follows: the scrolled window child's minimum width and minimum height under A) at least correspond to the space taken up by its scrollbars.

So, if you set POLICY_NEVER, the ScrolledWindow will request for itself all the place, required by its child (and possibly will bloat the screen, if its child is huge). Otherwise, it will request a minimum needed to draw scrollbars. Possibly more space will be allocated for it than was requested and it will get enlarged to a reasonable size within its parent.

Sometimes you might want to have 2 ScrolledWindows, sharing a single scrollbar. Unfortunately, it is impossible to just set POLICY_NEVER for one of them and have scrolled_window1.set_adjustment() = scrolled_window2.get_adjustment() due to the fact, that POLICIES influence the size requisition and scrolled_window1 will start to request unpredictable (possibly huge) amount of space.