summaryrefslogtreecommitdiff
path: root/gtk/gtkscrolledwindow.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert "scrolledwindow: Remove child before destroying self"Matthias Clasen2016-05-201-5/+0
| | | | | | | | This reverts commit dcb4b48b29559ca632bb020a3b8eb2b9188b02e7. This was causing crashes in the filechooser in some applications. https://bugzilla.gnome.org/show_bug.cgi?id=766694
* scrolledwindow: Fix typo in get_preferred_height calculationDebarshi Ray2016-05-191-3/+3
| | | | | | | | | | | | | | | | | When we are beginning to calculate the height, if the vscrollbar_policy is not GTK_POLICY_NEVER, and there is no min-content-height, then we need some small non-zero value to get started. The idea is to always ask for at least enough to fit the horizontal scrollbar. Simply put, this should be the mirror image of the corresponding width calculation code. Those who got used to the buggy behaviour might notice that their GtkScrolledWindows are not as tall as they used to be. Fall out from 55196a705f00564a44647bfc97981db0a783369a https://bugzilla.gnome.org/show_bug.cgi?id=766530
* scrolledwindow: Remove child before destroying selfBenjamin Otte2016-05-191-0/+5
| | | | | | Children tend to call back into the scrolled window while being removed and that doesn't work too well if the scrolled window is destroyed already as Christian Hergert found out.
* GtkScrolledWindow: Do not hover one scrollbar if grabbing on the otherCarlos Garnacho2016-03-141-2/+7
| | | | | Makes no sense since we're not going to interact with it. It'll be hovered eventually if the button is released.
* GtkScrolledWindow: Check proximity on both indicators on grab-end leave eventsCarlos Garnacho2016-03-141-4/+2
| | | | | | The implicit grab may be finished so the pointer lies on top of the other scrollbar, in this case one scrollbar should lose the hovering state, and the other should gain it. So we must check for proximity in both indicators.
* scrolled window: Fix scrollbar size allocationMatthias Clasen2016-03-111-11/+16
| | | | | | | | | | | 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.
* scrolledwindow: fix left/right thinko for scrollbar style classesCosimo Cecchi2016-03-021-4/+4
| | | | | | "left" and "right" were inverted, preumably because the position type parameter refers to the scrolled window position, and not the scrollbar itself.
* wayland: add gdk_event_is_scroll_stop_event()Peter Hutterer2016-01-181-1/+1
| | | | | | | | | | 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
* scrolledwindow: add missing deprecation flagCosimo Cecchi2015-12-301-1/+1
|
* scrolledwindow: port to use a gadgetCosimo Cecchi2015-12-291-658/+665
|
* scrolledwindow: deprecate scrollbars-within-bevel style propertyCosimo Cecchi2015-12-291-84/+8
| | | | | These days all the themes set it to TRUE, and it's not clear what happens with overlay scrollbars...
* scrolledwindow: Remove unneeded codeCarlos Garnacho2015-12-161-4/+0
| | | | We no longer take a grab here, no need to undo it on grab_notify
* Don't pass widget state flags to GtkStyleContext APITimm Bäder2015-11-221-5/+5
|
* scrolledwindow: Document overlay scrolling style classesMatthias Clasen2015-11-061-1/+2
| | | | | Document which style classes are used on scrollbars to implement overlay scrolling.
* scrolledwindow: Set positional classes on scrollbarsMatthias Clasen2015-11-061-4/+69
| | | | This might be useful for some themes.
* scrolled window: Drop unnecessary transient nodesMatthias Clasen2015-11-061-13/+0
| | | | | | We already add the .frame style class to the context depending on the shadow property. No need to save the context and add it again all the time.
* scrolledwindow: Use permanent CSS nodesMatthias Clasen2015-11-051-31/+42
| | | | | This avoids false inheritance due to gtk_style_context_save_named(), and is generally the right thing to do.
* scrolledwindow: Fix a typoKrzesimir Nowak2015-11-041-1/+1
|
* scrolledwindow: Port to CSS nodesMatthias Clasen2015-11-041-18/+23
| | | | | Change GtkScrolledWindow to use transient named CSS nodes for drawing the overshoot, undershoot and scrollbar junction.
* scrolled window: Protect against nameless devicesMatthias Clasen2015-10-151-2/+4
| | | | | | | It seems that gdk_device_get_name() can return NULL. We should not crash if that happens. https://bugzilla.gnome.org/show_bug.cgi?id=756625
* scrolledwindow: Set the scrollbar as "over" immediately during slider grabsCarlos Garnacho2015-09-161-2/+9
| | | | | | | | | | | | 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
* scrolledwindow: Cancel kinetic/overshoot animation on captured scroll eventsCarlos Garnacho2015-09-141-1/+6
| | | | | | | This ensures the animation is cancelled if the child widget happens to GDK_EVENT_STOP scroll events. https://bugzilla.gnome.org/show_bug.cgi?id=745315
* gtk: Stop setting GDK_EXPOSURE_MASK on random widgetsAlexander Larsson2015-09-141-2/+2
| | | | | | | | | | | | | | 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.
* scrolled window: Convert to g_object_notify_by_pspecMatthias Clasen2015-09-081-101/+92
|
* gtkscrolledwindow: Fold kinetic deceleration handling into scroll_event()Carlos Garnacho2015-08-191-29/+27
| | | | | | | | | | | | | | | | 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
* GtkScrolledWindow: Don't handle key event when can't scrollMarek Kasik2015-08-051-2/+12
| | | | | | | Don't return that a key event was handled when the corresponding scrollbar can not scroll. https://bugzilla.gnome.org/show_bug.cgi?id=753256
* scrolledwindow: Keep scrollbars out of GtkScrollable::get_borderCarlos Garnacho2015-07-061-1/+1
| | | | | | | It looks a bit odd that scrollbars stay over treeview headers and similar, seems nicer to just avoid the border regions. https://bugzilla.gnome.org/show_bug.cgi?id=751805
* scrolledwindow: fix copy/paste typoCosimo Cecchi2015-05-241-1/+1
| | | | | fc2830394895f236352bea2024dda0e962dd2c53 refactored code into the get_scroll_unit() function but introduced a copy/paste typo.
* scrolledwindow: Trigger builtin kinetic deceleration on libinput devicesCarlos Garnacho2015-05-241-15/+131
| | | | | | | | | | | | | 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
* scrolledwindow: Refactor scroll unit guessing into a separate functionCarlos Garnacho2015-05-241-16/+32
| | | | | | Makes it clearer, and will be used in further places. https://bugzilla.gnome.org/show_bug.cgi?id=749770
* scrolledwindow: reset more Indicator state on ::unmapCarlos Garnacho2015-05-221-0/+10
| | | | | | | | | | | 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.
* scrolledwindow: Do not round dx/dy to intCarlos Garnacho2015-04-161-1/+1
| | | | | | 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 d563b943ed3.
* scrolledwindow: Ensure the animation is cancelled on arriving scroll eventsCarlos Garnacho2015-04-161-0/+1
| | | | | | | 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.
* scrolledwindow: Show scrollbars on tablet devicesCarlos Garnacho2015-04-131-3/+5
| | | | | | | | | 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
* Fix indicator proximity checksMatthias Clasen2015-04-061-27/+53
| | | | | | | | | 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
* Make indicators pop out when neededMatthias Clasen2015-04-061-3/+4
| | | | | | | | | | 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
* scrolledwindow: Ignore 0/0 scroll events when possibly cancelling animationCarlos Garnacho2015-04-011-1/+12
| | | | | | | These should be used eventually to start kinetic scrolling, so should definitely be ignored on cancellation. https://bugzilla.gnome.org/show_bug.cgi?id=747133
* scrolledwindow: Remove needless "dragging" field from Indicator structCarlos Garnacho2015-03-311-17/+2
| | | | | | | The "over" state already stays set while scrollbar dragging happens, there's no need to double track that. https://bugzilla.gnome.org/show_bug.cgi?id=746961
* scrolledwindow: Check the event widget on captured motion eventsCarlos Garnacho2015-03-311-8/+10
| | | | | | | | 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
* scrolledwindow: Extend trackpoint heuristic to ALPS trackpointsHans de Goede2015-03-261-1/+2
| | | | | These have a different characteristic device name, look for it too in order to enable trackpoint features.
* scrolled window: Use shift to modify scroll directionMatthias Clasen2015-03-171-3/+17
| | | | | | | | 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
* scrolled window: Fix size requisition with overlay scrollingMatthias Clasen2015-03-071-18/+14
| | | | | | | 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.
* scrolledwindow: Cancel kinetic/overshoot animation on captured scroll eventsCarlos Garnacho2015-03-021-1/+6
| | | | | | | This ensures the animation is cancelled if the child widget happens to GDK_EVENT_STOP scroll events. https://bugzilla.gnome.org/show_bug.cgi?id=745315
* scrolledwindow: Add motion mask to the widget windowCarlos Garnacho2015-03-021-1/+1
| | | | | | | | 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
* scrolledwindow: Only start fade animation on "visible" scrollbarsCarlos Garnacho2015-02-241-2/+4
| | | | | | 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.
* scrolled window: Avoid a crashMatthias Clasen2015-02-201-1/+1
| | | | | | | | | | | 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.
* scrolled window: Drop dead codeMatthias Clasen2015-02-201-3/+0
| | | | | The allocation is never used in this function, so don't bother getting it.
* scrolledwindow: Ensure indicator windows are created at the right placeCarlos Garnacho2015-02-171-95/+125
| | | | | | | | | | | | | | | | | | 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.
* scrolledwindow: Fully reset indicators' state on unrealizeCarlos Garnacho2015-02-171-4/+37
| | | | | This avoids timers to run after realize(), and inconsistent initial states if the scrolledwindow is just realized again.
* scrolledwindow: Don't hover the scrollbars while a button is being pressedCarlos Garnacho2015-02-051-1/+7
| | | | | | | | | 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
View Lorry Controller Status