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.
The GtkScrollable interface provides "hadjustment" and "vadjustment"
properties that are used by GtkScrolledWindow. It replaces
the ::set_scroll_adjustment signal. The scrollable interface
also has ::min-display-width/height properties that can be
used to control the minimally visible part inside a scrolled window.
Some GtkSettings property are registered by other classes. This leads
to the "interesting" issue that setting GtkSettings:gtk-button-images
requires that the GtkButton class is referenced first - or that a
GtkButton is created.
https://bugzilla.gnome.org/show_bug.cgi?id=632538
Removed portion of scrolled-window that observes user-set
size request data (aux_info->width/height) on the child directly
in order to derive it's minimum possible size... if the scrolled
window has (auto/always) scrollbars in a said orientation; only
request enough space for the scrollbars (bug 631976).
This patch makes the scrolled window reconsider allocating the child
the full width or height (depending on the child's request mode) without
a scrollbar. For instance when the child is height-for-width; the child
will first be tested if the content's height for full allocated width
(without a vscrollbar) will allow the contents height for that width
to fit the allocated height.
Patch is a simplified version of code inspected in st-scroll-view.c.
Note that this patch assumes children will begin to scroll only after
reaching their minimum size; adding a property to the future
GtkScrollableIface to decide whether to scroll-to-minimum or scroll-to-natural
will effect this code (it should then reconsider whether the child
will scroll below the natural size instead of the minimum).
Patch addresses bug 629778.
It doesn't make sense to keep them separate as GtkSizeRequest requires a
GtkWidget and GtkWidget implements GtkSizeRequest, so you can never have
one without the other.
It also makes the code a lot easier because no casts are required when
calling functions.
Also, the names would translate to gtk_widget_get_width() and people
agreed that this would be a too generic name, so a "preferred" was added
to the names.
So this patch moves the functions:
gtk_size_request_get_request_mode() => gtk_widget_get_request_mode()
gtk_size_request_get_width() => gtk_widget_get_preferred_width()
gtk_size_request_get_height() => gtk_widget_get_preferred_height()
gtk_size_request_get_size() => gtk_widget_get_preferred_size()
gtk_size_request_get_width_for_height() =>
gtk_widget_get_preferred_width_for_height()
gtk_size_request_get_height_for_width() =>
gtk_widget_get_preferred_height_for_width()
... and moves the corresponding vfuncs to the GtkWidgetClass.
The patch also renames the implementations of the vfuncs in widgets to
include the word "preferrred".
