When adding with a viewport we automatically set the focus
adjustments on the viewport from the scrolled window, so that
when any child widget gets focused we automatically scroll to it.
This is generally nice, but its particularly important for GtkListBox
where focus changing is how we navigate between rows.
We also ensure that the adjustments are always set before adding the
child to the viewport, which we will need later to pick up the
adjustments on add.
Deprecate gtk_widget_push_composite_child, gtk_widget_pop_composite_child,
gtk_widget_set_composite_name, gtk_widget_get_composite_name.
This API is just bloat and was never useful, this patch deprecates
it and removes all internal calls to the composite child APIs
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
There's really no reason why we shouldn't automatically create a
GtkViewport when the widget added to GtkScrolledWindow is not a
GtkScrollable, instead of just printing a g_warning.
Copy the viewport special case into the scrolled window implementation
of gtk_container_add().
https://bugzilla.gnome.org/show_bug.cgi?id=693015
We want to reserve space for the size of the scrollbars even when they
are not visible. And because toggling visibile to off now returns 0 for
size requests, this won't work anymore.
Currently we use gtk_style_context_set_background() when the state flags
change in order to propagate the background color to the overshoot
window, but this is actually only needed because the window doesn't get
expose events, since we always draw a full background in draw().
This also fixes some problems when the GdkWindow of the scrolled
window's child is composited, as seen in oxygen-gtk3.
https://bugzilla.gnome.org/show_bug.cgi?id=686265
When positioning the scrollbar we were doing several miscalculations
when accounting for CSS paddings and borders. This also fixes a number
of problems with RTL and when scrollbars-within-bevel is FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=685449
GtkTextHandle creates temporary override redirect windows, but still
hook to the text widget for events, so those are effectively captured
by GtkScrolledWindow if a text widget is within it
- don't poke at the children's background pattern at draw time, but just
call gtk_render_background()
- we should propagate rendering of the background to the overshoot
window when the state flags or the style changes, or it won't respond
to e.g. focused/backdrop changes correctly
https://bugzilla.gnome.org/show_bug.cgi?id=682854
When the scrolled window has a frame (and the scrollbar is within the
bevel), we should take into account the CSS border/padding of the frame
and offset the scrollbars junction rendering with it.
If delta_x/y information is provided in scroll events, use it
to modify the underlying adjustment in steps proportional to
the deltas provided.
If the child widget of a scrolledwindow doesn't set
GDK_SMOOTH_SCROLL_MASK, regular scroll events will be dispatched,
and still handled by these 2 widgets.
Kinetic scrolling is only done on touch devices, since it is
sort of meaningless on pointer devices, besides it implies
a different input event handling on child widgets that is
unnecessary there.
If the scrolling doesn't start after a long press, the scrolling is
cancelled and events are handled by child widgets normally.
When clicked again close to the previous button press location
(assuming it had ~0 movement), the scrolled window will allow
the child to handle the events immediately.
This is so the user doesn't have to wait to the press-and-hold
timeout in order to operate on the scrolledwindow child.
The innermost scrolled window always gets to capture the events, all
scrolled windows above it just let the event go through. Ideally
reaching a limit on the innermost scrolled window would propagate
the dragging up the hierarchy in order to keep following the touch
coords, although that'd involve rather evil hacks just to cater
for broken UIs.
If there's a junction between the two scrollbars (i.e. they're both
visible), draw a background with a style class there, so the theme can
style it.
https://bugzilla.gnome.org/show_bug.cgi?id=669335
Fixed the hangs by adding a ->inside_allocation flag and avoiding to
queue resizes while inside the allocation loop. The extra queue'd resizes
were causing the scrolled window size_allocate() to perform the guess
again and again thus causing an infinite loop.
Seems with GtkScrollable interface we were setting the hadjustment as
the vadjustment, thanks to Cosimo Cecchi who debugged this and finally
found the typo.
This patch adds the GtkScrollablePolicy type property to GtkScrollable
and implements it in all subclasses. GtkScrolledWindow observes this
property to make a good guess about when to show/hide scrollbars for
height-for-width content.
Most scrollable children do not do height-for-width *yet* but
most certainly will (toolpalette, treeview, iconview, textview
widgets all TODO), for scrollable widgets that do have a minimum
and natural size, it's important for them to observe the state
of this property in order to properly drive the scroll adjustments
according to the desired GtkScrollablePolicy. This patch makes
GtkViewport do this.
Patch also adds tests/testscrolledwindow.c to display the effects
of this property.
It is just too annoying to have to implement these properties in
every scrollable. Instead, we now have ::min-content-height/width
in GtkScrolledWindow.
We also add GtkScrollablePolicy to determine how to size the
scrollable content.
