gtk-bin, gtk-container, gtk-widget, g-initially-unowned, gtk-buildable, g-object, common-lisp:standard-object, common-lisp:t
gtk-scrolled-window is a gtk-bin subclass: it is a container the accepts a single child widget. gtk-scrolled-window adds scrollbars to the child widget and optionally draws a beveled frame around the child widget.
The scrolled window can work in two ways. Some widgets have native scrolling support; these widgets implement the gtk-scrollable interface. Widgets with native scroll support include gtk-tree-view, gtk-text-view, and gtk-layout.
For widgets that lack native scrolling support, the gtk-viewport widget acts as an adaptor class, implementing scrollability for child widgets that lack their own scrolling capabilities. Use gtk-viewport to scroll child widgets such as gtk-grid, gtk-box, and so on.
If a widget has native scrolling abilities, it can be added to the gtk-scrolled-window with the function gtk-container-add. If a widget does not, you must first add the widget to a gtk-viewport, then add the gtk-viewport to the scrolled window. The convenience function gtk-scrolled-window-add-with-viewport does exactly this, so you can ignore the presence of the viewport.
The position of the scrollbars is controlled by the scroll adjustments. See the function gtk-adjustment for the fields in an adjustment - for gtk-scrollbar, used by gtk-scrolled-window, the value slot represents the position of the scrollbar, which must be between the lower slot and upper - page-size. The page-size slot represents the size of the visible scrollable area. The step-increment and page-increment slot are used when the user asks to step down (using the small stepper arrows) or page down (using for example the PageDown key).
If a gtk-scrolled-window does not behave quite as you would like, or does not have exactly the right layout, it is very possible to set up your own scrolling with gtk-scrollbar and for example a gtk-grid.
Touch support gtk-scrolled-window has built-in support for touch devices. When a touchscreen is used, swiping will move the scrolled window, and will expose 'kinetic' behavior. This can be turned off with the "kinetic-scrolling" property if it is undesired.
gtk-scrolled-window also displays visual 'overshoot' indication when the content is pulled beyond the end, and this situation can be captured with the "edge-overshot" signal.
If no mouse device is present, the scrollbars will overlayed as narrow, auto-hiding indicators over the content. If traditional scrollbars are desired although no mouse is present, this behaviour can be turned off with the "overlay-scrolling" property.
gtk-scrolled-window has a main CSS node with name scrolledwindow.
It uses subnodes with names overshoot and undershoot to draw the overflow and underflow indications. These nodes get the .left, .right, .top or .bottom style class added depending on where the indication is drawn.
gtk-scrolled-window also sets the positional style classes .left, .right, .top, .bottom and style classes related to overlay scrolling .overlay-indicator, .dragging, .hovering on its scrollbars.
If both scrollbars are visible, the area where they meet is drawn with a subnode named junction.
Style Property Details
The "edge-overshot" signal
lambda (scolled-window pos) : Run LastThe "edge-overshot" signal is emitted whenever user initiated scrolling makes the scrolled window firmly surpass, i.e. with some edge resistance, the lower or upper limits defined by the adjustment in that orientation. A similar behavior without edge resistance is provided by the "edge-reached" signal. Note: The pos argument is LTR/RTL aware, so callers should be aware too if intending to provide behavior on horizontal edges.
The "edge-reached" signallambda (scrolled-window pos) : Run Last The "edge-reached" signal is emitted whenever user-initiated scrolling makes the scrolled window exactly reach the lower or upper limits defined by the adjustment in that orientation. A similar behavior with edge resistance is provided by the "edge-overshot" signal. Note: The pos argument is LTR/RTL aware, so callers should be aware too if intending to provide behavior on horizontal edges.
The "move-focus-out" signal
lambda (scrolled-window direction-type) : ActionThe "move-focus-out" signal is a keybinding signal which gets emitted when focus is moved away from the scrolled window by a keybinding. The "move-focus" signal is emitted with direction-type on this scrolled windows toplevel parent in the container hierarchy. The default bindings for this signal are Tab+Ctrl and Tab+Ctrl+Shift.
The "scroll-child" signal
lambda (scrolled-window scroll horizontal) : ActionThe "scroll-child" signal is a keybinding signal which gets emitted when a keybinding that scrolls is pressed. The horizontal or vertical adjustment is updated which triggers a signal that the scrolled windows child may listen to and scroll itself.
Slot Access Functions
Inherited Slot Access Functions