summaryrefslogtreecommitdiff
path: root/gtk/gtkrange.c
Commit message (Collapse)AuthorAgeFilesLines
* Rename GtkGestureMultiPress to GtkGestureClickMatthias Clasen2019-05-291-17/+17
| | | | | The name just made it hard for people to find the right gesture to use.
* Remove gtk_widget_get/set_has_surfaceMatthias Clasen2019-05-281-2/+0
| | | | | These serve no purpose anymore - widgets don't have surfaces, unless they're a GtkNative.
* range: Use standard paddingMatthias Clasen2019-05-261-0/+1
|
* Rename thingsMatthias Clasen2019-04-081-1/+1
| | | | | Rename the can-pick property to can-target, and redo the pick flags with more descriptive names.
* Add a flags argument to gtk_widget_pickMatthias Clasen2019-04-071-2/+2
| | | | | | | This will be used to let the inspector and other users pick insensitive widgets again. For now, update all callers to pass no flags, preserving the current behavior.
* gizmo: Add a contains_funcMatthias Clasen2019-04-071-4/+5
| | | | | Let GtkGizmo override the contains() implementation. Update all callers to pass NULL for the contains_func.
* gtk: Check return value of compute_bounds()Benjamin Otte2019-02-201-21/+34
| | | | | Half of these calls will completely break if anybody ever uses CSS transforms with them, but hey...
* Remove some unnecessary gtkwindow.h includesTimm Bäder2019-02-051-1/+0
|
* gtk: Drop the "plus"Emmanuele Bassi2019-02-051-2/+2
| | | | Source names should use "[gtk]" without the plus.
* Remove :active state handling on widgetsTimm Bäder2019-01-291-27/+0
|
* gizmo: return void from snapshot funcTimm Bäder2019-01-181-4/+2
| | | | | This boolean return was from the old gadget code and we weren't using it in the new gizmo code.
* colorscale: Redraw correct widget after setting rgbaTimm Bäder2019-01-161-0/+8
| | | | | | | | | The entire color scale hack is still done in GtkRange, which draws the color scale in the range gizmo. So, to correctly redraw the color scale when setting a new color, we need to redraw the proper widget and that's the trough widget. Fixes #1453
* Use g_clear_pointer to unparent widgetsTimm Bäder2018-11-131-13/+6
|
* widget: Don't pass a position to ->size_allocateTimm Bäder2018-11-131-38/+43
| | | | | The values have been 0/0 for a long time now, so just drop the GtkAllocation argument and replace it with width and height.
* eventcontrollerscroll: Conditionally propagate ::scrollErnestas Kulik2018-11-121-2/+4
| | | | | | | | | | | | Currently, gtk_event_controller_scroll_handle_event() always returns TRUE if it is handled, which stops the propagation of the event. If there’s a single GtkEventControllerScroll in the widget hierarchy, that means that no others will run, depending on the propagation phase. In Nautilus, this can be observed when adding a scroll controller to the GtkScrolledWindow (ctrl-scrolling controls the zoom level) - either the scrolling or the zooming breaks. Fixes https://gitlab.gnome.org/GNOME/gtk/issues/45
* colorscale: Remove x/y arguments from snapshot_scaleTimm Bäder2018-11-091-1/+0
| | | | We only pass 0 anyway.
* range: Remove multipress_gesture memberTimm Bäder2018-11-081-9/+8
| | | | | We don't need it in the instance struct since we only set it up and then access it in its signal callbacks.
* range: Remove has_origin flagTimm Bäder2018-07-081-10/+4
| | | | It's equivalent to the highlight_widget being !NULL.
* Range: Up should only mean ++ if we are a GtkScaleDaniel Boles2018-05-211-2/+2
| | | | | | | | | | The last round of patches to get the desired direction of value move in response to scrolls/keypresses on scales had the inadvertent side effect of giving the opposite direction on scrollbars. Seeing as gtkrange.c is already a collection of hacks, add another so that fix only holds if the instance is a GtkScale, since that is what those patches were aimed at. Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
* eventcontrollerkey: Port to new API modelCarlos Garnacho2018-04-261-6/+3
|
* eventcontrollerscroll: Port to new API modelBenjamin Otte2018-04-261-6/+4
|
* draggesture: Port to new API modelBenjamin Otte2018-04-261-2/+2
|
* longpressgesture: Port to new API modelBenjamin Otte2018-04-261-6/+6
|
* multipressgesture: Port to new API modelBenjamin Otte2018-04-261-3/+3
|
* range: Do not unconditionally stop events in event handlerCarlos Garnacho2018-04-251-1/+1
| | | | Prevents keybindings from working on scales.
* Range: Make down/up keys act like down/up scrollsDaniel Boles2018-04-181-8/+8
| | | | | | | | | | | Before now, down/up keys on H Ranges would increase/decrease value resp, which is unintuitive & worse, contradicts what we already do for scrolls Fix simply by moving to the new should_invert_move() as scrolls just did – which also gets us the other benefits explained in the last 2 commits. https://bugzilla.gnome.org/show_bug.cgi?id=407242 https://bugzilla.gnome.org/show_bug.cgi?id=791802
* Range: Use should_invert_move() to scroll valueDaniel Boles2018-04-181-4/+11
| | | | | | | This fixes RTL and/or :inverted Ranges responding to a horizontal scroll by moving the value/slider button in the opposite direction... See prev. https://bugzilla.gnome.org/show_bug.cgi?id=791802
* Range: Add should_invert_move() for scrolls & keysDaniel Boles2018-04-181-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will be used in subsequent commits to fix the sign by which the value is changed in response to directional scroll or keypress events. The idea is: you have a movement to make – in the form of a delta that follows widget directions, i.e. −1 means left or up, +1 means right or down – and you want to know whether that delta needs to be inverted in order to produce the intuitively expected directional change of :value. The existing should_invert() is not sufficient: it just determines whether to invert visually, but we need more nuance than that for input. To answer that – while not doubling up the work for scrolls and keys – I add a helper should_invert_move(), which considers other relevant state: • A parallel movement on priv->orientation should just use the existing should_invert(), which already worked OK for this case (not others). • Movements on the other orientation now depend on priv->orientation: ◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of widget coords) always means increase value & vice-versa. This was done in get_wheel_delta(), but move it here for use with keys too. ◦ For a vertical Range, ignore :invert as it’s only relevant to the parallel orientation. Do not care about text direction here either as RTL locales do not invert number lines, Cartesian plots, etc. This returns TRUE if the delta should be inverted before applying to the value, and we can now use this function in both scroll and key handlers. https://bugzilla.gnome.org/show_bug.cgi?id=407242 https://bugzilla.gnome.org/show_bug.cgi?id=791802
* widget: Remove _get_own_allocationTimm Bäder2018-04-101-27/+34
| | | | Replace all usages of it with _compute_bounds
* gtkrange: Stop using ::key-press-eventCarlos Garnacho2018-04-051-15/+19
| | | | Use GtkEventControllerKey for the task
* widget: Remove clip from size-allocate vfuncBenjamin Otte2018-04-051-15/+10
| | | | As the clip is no longer needed, get rid of it.
* GtkWidget: Start renaming widget->windowAlexander Larsson2018-03-201-1/+1
| | | | | | | | | | | | | | | This is an automated change doing these command: git sed -f g gtk_widget_set_has_window gtk_widget_set_has_surface git sed -f g gtk_widget_get_has_window gtk_widget_get_has_surface git sed -f g gtk_widget_set_parent_window gtk_widget_set_parent_surface git sed -f g gtk_widget_get_parent_window gtk_widget_get_parent_surface git sed -f g gtk_widget_set_window gtk_widget_set_surface git sed -f g gtk_widget_get_window gtk_widget_get_surface git sed -f g gtk_widget_register_window gtk_widget_register_surface git sed -f g gtk_widget_unregister_window gtk_widget_unregister_surface git checkout NEWS*
* range: Fix typo in allocate_troughTimm Bäder2018-02-231-1/+1
| | | | lower - upper results in something negative of course.
* range: Fix coord/value translationTimm Bäder2018-02-231-33/+39
| | | | | Save the x/y we allocated the slider at, which is different than the coordinates we get from any of the widget allocation accessors.
* range: Compute slider allocation in update_initial_slider_positionTimm Bäder2018-02-231-14/+13
| | | | Instead of outside at every call-site.
* range: Remove GtkScale special casingTimm Bäder2018-02-231-14/+0
| | | | | This is unnecessary these days due to the negative margins of the slider.
* range: Simplify allocate_troughTimm Bäder2018-02-231-14/+9
|
* range: Simplify compute_slider_positionTimm Bäder2018-02-231-12/+11
|
* range: Fix coordinates in coord_to_valueTimm Bäder2018-02-231-12/+13
| | | | | | The given coordinate needs to be trough-relative, since that's what the slider is relative to. Also use the trough's content size and not the outer size.
* range: Remove some unneeded includesTimm Bäder2018-02-231-3/+0
|
* range: Remove priv pointerTimm Bäder2018-02-231-114/+122
|
* range: Stop tracking mouse positionTimm Bäder2018-02-231-45/+14
| | | | | We have the mouse position available everywhere we want to use it anyway, so use that instead.
* range: Stop tracking mouse locationTimm Bäder2018-02-231-39/+16
| | | | | Instead, just use gtk_widget_pick() to get the widget at the pointer position whenever we need it.
* range: Don't call calc_slider() on value changesTimm Bäder2018-02-231-2/+0
| | | | | calc_slider() updates the slider visibility, but that can only change if the upper or lower change.
* range: Remove unnecessary queue_draw callsTimm Bäder2018-02-231-4/+0
|
* range: Remove scale special caseTimm Bäder2018-02-231-6/+0
| | | | | This is done automatically nowadays since the value is shown in a widget.
* a11y: Don't include gtk.hBenjamin Otte2018-02-081-8/+11
| | | | | Also add missing includes and sort them for all the widgets that relied on that before.
* The big versioning cleanupMatthias Clasen2018-02-061-38/+0
| | | | | | | Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
* Replace gdk_threads_add_timeout* with g_timeout_add()Emmanuele Bassi2018-02-031-6/+2
| | | | | | | | | | | | | | | The main GDK thread lock is not portable and deprecated. The only reason why gdk_threads_add_timeout() and gdk_threads_add_timeout_full() exist is to allow invoking a callback with the GDK lock held, in case 3rd party libraries still use the deprecated gdk_threads_enter()/gdk_threads_leave() API. Since we're removing the GDK lock, and we're releasing a new major API, such code cannot exist any more; this means we can use the GLib API for installing timeout callbacks. https://bugzilla.gnome.org/show_bug.cgi?id=793124
* range: Always queue an allocate if the adjustment changedTimm Bäder2018-01-301-3/+1
| | | | | The slider gets its new size in size-allocate, so we have to do this even if the range has no origin.
View Lorry Controller Status