We were not taking the scrollable borders into account when
requesting size for the scrolled window, which could lead
to underallocating the scrollbars at size allocation time
when we *did* take the borders into account.
This is most notable with treeviews, where we have the
headers as borders, and was causing the treeview-crash-too-wide
reftest to fail.
And use it to handle kinetic scrolling in the GtkScrolledWindow.
However, dropping the delta check causes the X11-based kinetic
scroll to break since we don't have the stop event here. Correct handling of
xf86-input-libinput-based scroll events is still being discussed.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
Otherwise it's attempted through a timeout, which gets cancelled early after,
and the slider disappears after a while with no mouse activity despite the
ongoing implicit grab.
Once the grab is finished, check_update_scrollbar_proximity() will be called
again on both scrollbars, and the fade out animation will be triggered as a
result.
https://bugzilla.gnome.org/show_bug.cgi?id=754745
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
In order to play along with child widgets that use scroll events for anything
else than scrolling, it will be better to do this in the bubble phase, so
the child widget has an opportunity to GDK_EVENT_STOP the event before we
trigger kinetic scrolling.
This of course won't work for widgets that choose to reimplement scroll event
handling themselves, they should be smart at resorting to GtkScrolledWindow's
scroll event handling.
This fixes kinetic scrolling kicking in too pervasively on widgets that eg.
implement zoom on scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=753495
The libinput driver will send a 0/0 scroll event on touchpads and other
devices where it knows scrolling stopped for sure. Use these events to
trigger kinetic scrolling from there.
The mechanism is similar to GtkGestureSwipe, we keep a backlog of the
latest dx/dy till a previous point in time, and calculate the final
velocities from there, with the difference we're dealing with scroll
units, and not pixel distances.
https://bugzilla.gnome.org/show_bug.cgi?id=749770
If a GtkScrolledWindow is just unmapped and promptly mapped again, the
indicators are left in a semi-visible state, so the GdkWindow isn't raised
properly above scrolledwindow content. This inconsistent state went away
the next time the indicator is hidden.
So, reset all state about indicator window visibility, animation
progress and conceil timer on ::unmap, this will be enough to make the
indicators start out hidden like on newly created scrolledwindows.
Libinput will use 0.0f on the "scrolling finished" event, so check for this
instead of rounding (<1 values are sort of frequent on touchpads). This
impedes bug #745315 to resurface after commit d563b943ed.
When the scrolledwindow receives scroll events, it ensures the timeout to
maybe start the "snap back to edges" animation is reset, but it does nothing
about the animation source. It must be reset just the same, to maybe be
started after the timeout fires up.
The code managing scrollbars visibility was too pervasively checking for
mouse devices, leaving pen/eraser/cursor devices with no scrollbars at
all. Relax these checks a bit, and actually toggle full-width scrollbars
on pen/eraser devices, so it is an easier target.
https://bugzilla.gnome.org/show_bug.cgi?id=747608
The coordinate translations here were not working properly
for window widgets inside the scrolled window, as can be
seen e.g. for the horizontal scrollbar of the 'Tree View'
example in gtk3-demo.
https://bugzilla.gnome.org/show_bug.cgi?id=747406
When moving over a non-expanded indicator from the outside, we were
not expanding it, due to on_scrollbar being true. This can be seen
e.g. when moving from the content pane over to the sidebar indicator
in gtk3-demo. We must still ensure that the indicator is expanded
when receiving motion events over the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=747407
This path is only intended to be triggered on events directed towards the
child of the scrolledwindow, so make it explicitly so. This avoids scrollbar
"over" state flashing when dragging finishes within the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=746961
It has been a long-standing request to interpret scroll events
with Shift held down as horizontal instead of vertical, and
some applications are already doing this on their own.
https://bugzilla.gnome.org/show_bug.cgi?id=132197
When the scrollbars are overlayed, the size requisition of the
scrolled window should not depend on whether the scrollbars are
visible or not. This was not quite the case, because we forgot
one case where scrollbar size was still added to the requisition.
This is not specified specifically by the attached controllers, so let
the scrolledwindow set the mask, as motion events with no buttons pressed
are interesting to it.
https://bugzilla.gnome.org/show_bug.cgi?id=745344
If a scrollbar is not shown (because of policies, or because it isn't
necessary), it doesn't make sense to start fade animations on its window
on captured motion events.
gtk_scrolled_window_allocate_scrollbar was calling
gtk_scrolled_window_allocate_child just to get the relative
allocation, overlooking the fact that that function is only
safe to call if the scrolled window _has_ a child. Unfortunately,
gtk_scrolled_window_allocate_scrollbar will sometimes get called
when that is not the case. Since we are really only interested
in the relative allocation, just get that directly. This
fixes a segfault in the style-properties-nth-child reftest.
At the time of creating the indicator window, the scrollbar allocation is
poked and reused as the initial window dimensions. This usually happens
on two circumstances, either initially (so a ::size-allocate is emitted,
relocating the windows in the right places), or post-initialization when
calling set_overlay_scrolling() (so the scrollbars already have a valid
size allocation)
However, if the scrolledwindow is unrealized, and later re-realized again,
the scrollbars will already have a valid allocation, although 0,0 based
due to being contained in the previous indicator window. This comes out
wrong then, and the indicator window is given 0,0 based coordinates too.
Fix this by refactoring the scrollbar allocation code out of size_allocate,
and also use that given size at the time of creating the indicator windows,
this will provide the right widget-relative allocation anytime.
This avoids showing the scrollbars if we are positive the child widget
is being manipulated, regardless of the pointer being close to any of these.
On the next motion event after finishing the operation, the scrollbar will
be shown if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=743894
In that case the scrolledwindow still gets events through the captured
handler, and can thus still control visibility, so hiding the indicators
in this case can only lead to flashing.
This will be used to just detect when an edge of the scrollable area is
reached - as opposed to the edge-overshot signal that is emitted when
the user scrolls past the edge.
https://bugzilla.gnome.org/show_bug.cgi?id=742848
This was left unmodified when GtkScrolledWindow was made a windowed widget.
Displacing here by the widget allocation is not necessary anymore, since
we are invalidating the window set at these coordinates.
This patch is a simplification of a previous one by Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=742243
When we get a leave event, we need to remove the over bit,
since we may not get motion events that tell us when we lose
proximity, but we don't have to fade out right away - that
will happen on its on due to inactivity a bit later. Having
the indicator stay visible for a bit feels more relaxed.
This is so we can detect crossing events on the scrolledwindow widget,
which can be useful for toggling certain behaviors or not depending on
whether the mouse is on the widget.
Use the new scrollable API for getting non-scrollable borders
and draw over/undershoot at the right place. In practice, this
means that they now appear below treeview headers.
When overshooting through touchpad kinetic scrolling, the scrollbar remains
mostly static as it already hit a boundary. However, the fade in/out checks
are constantly run during scroll events, causing needless redraws in this
specific case.
The scrollbars are still internal children of the GtkScrolledWindow
and handled in ::forall(), no need to propagate draw here again
after chaining up in ::draw().
This commit adds a mode to GtkScrolledWindow in which it puts
narrow, auto-hiding scrollbars over the content, instead of
allocating room for the scrollbars outside of the content. We
use traditional scrollbars if we find a mouse or if overlay
scrolling has explicitly turned off.
For test purposes, GTK_TEST_TOUCHSCREEN can be used to get
overlay scrolling even in the presence of a mouse. The
environment variable GTK_OVERLAY_SCROLLING can also be used
to force overlay scrolling on or off.
This signal is emitted whenever user scrolling hits the overshoot
edge in the given direction. May be useful to add "reload" or "load
more" behaviors in apps.
https://bugzilla.gnome.org/show_bug.cgi?id=738534
Instead of making assumptions about enum value ordering,
introduce a helper function to determine policy values
for which the scrollbar may be visible.
Add a new policy, GTK_POLICY_EXTERNAL, which hides the scrollbar,
but does not force the scrolled windows size to be determined by
its child. This can be used to keep two scrolled windows in sync,
while sharing a single scrollbar.
https://bugzilla.gnome.org/show_bug.cgi?id=730730
Instead of drawing a gradient in the background color, draw a CSS box.
And change the theme so instead of setting just a background color it
draws a gradient.
The resulting visuals are the same.
This is a temporary workaround for scrolling units being amplified
on quartz, due to the assumption that smooth scrolling deltas are
always in some abstract unit similar to the one from xi2.
A proper solution for the situation is described in bug #736121, but
since we are close to release, this patch solves the issue temporarily.
https://bugzilla.gnome.org/show_bug.cgi?id=736121
The previous way to invalidate was meant to work on the overshoot window
so it wouldn't be as taxing. Since the overshoot window is gone, this
would invalidate way more than intended. So constrain invalidated areas
to the sides where overshoot is happenning at that moment.
https://bugzilla.gnome.org/show_bug.cgi?id=735223
The displacement animation has been replaced by edge gradients, that
have a stronger color the harder overshooting is hit. This makes it
possible to remove the internal overshoot window, which was merely
used to have contents displaced when overshooting to top/left.
Overshooting to bottom/right used to cause queue_resize() to be
called on the scrolled window, this isn't necessary anymore either.
https://bugzilla.gnome.org/show_bug.cgi?id=731297
We use gtk_adjustment_enable_animation to enable animated
updates of the adjustments. Currently, this is enabled
unconditionally, and with a duration that is hardcoded.
https://bugzilla.gnome.org/show_bug.cgi?id=732376
Translate shadow != None into the FRAME style class.
This doesn't change the style classes used for drawing,
it only sets the style class permanently instead of
saving and restoring in draw().
https://bugzilla.gnome.org/show_bug.cgi?id=732256
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
A pan gesture is optionally attached if there is only one scrolling direction, the pan
gesture orientation is changed so movements tangential to the scroll direction get
scrolling cancelled (The pan gesture is automatically denied when that happens, and
that state change spreads to the others gestures in the group). If the pan direction
happens in the expected directions, no cancellation happens, and scrolling eventually
takes place.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
With gtk_gesture_get_point() returning events in
gtk_event_controller_get_widget() coordinates, we no longer need
to compensate for the overshoot here.
The kinetic scrolling feature is now implemented using a
GtkGestureDrag and a GtkGestureSwipe, plus a GtkGestureLongPress
in order to denying the sequence, so it is possibly handled
underneath.
The change to take out unneeded NULL checks requires some care
at startup: we check both adjustments when any of them changes;
we need to do those checks in the same order in which we create
the scrollbars, otherwise we'll try to get the adjustment of
the vscrollbar when we just set the up the hscrollbars' adjustment.
Ensure the hscrollbar & vscrollbar at gtk_scrolled_window_add() time,
this allows one to subclass GtkScrolledWindow with templates and add
children, as this will happen at instance initialization time before
the construct adjustment properties take effect.
The tick callback IDs from GtkWidget aren't timeouts, so
use the correct function to disconnect from them.
Spotted by Benjamin Otte <otte@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710666
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.
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".
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
