summaryrefslogtreecommitdiff
path: root/gtk/gtkrange.c
Commit message (Collapse)AuthorAgeFilesLines
* all: Add names to timeoutsBastien Nocera2013-10-231-0/+2
| | | | | | | Add names to every timeout we setup, so it's easier to track their usage, and debug possible misbehaviour. https://bugzilla.gnome.org/show_bug.cgi?id=710651
* range: start autoscrolling near the edges of rangesWilliam Jon McCann2013-10-071-2/+3
| | | | | | | If a range goes all the way to the edge of the screen then we don't have any way to activate autoscrolling. By adding a small region at the ends of the range we can handle this case. This is the same approach used in treeviews.
* Add autoscroll when dragging past boundary of rangeWilliam Jon McCann2013-08-051-13/+119
| | | | | | | | | | | | | A problem with the zoom scroll mode is that you have to restart if you hit the bottom of the screen before you hit the bottom of your document. This commit adds an autoscroll feature to the zoom scroll: if you move outside the window while in zoom scroll mode, we keep scrolling in the direction you were going until you let go of the mouse button. https://bugzilla.gnome.org/show_bug.cgi?id=704703
* Add press and hold support to set zoom scroll modeWilliam Jon McCann2013-08-051-4/+82
| | | | | | | | | | | Triggering zoom scroll mode by Shift click was too much of an easter egg. It also requires using keyboard and mouse together, which is hard to do for many users. Instead, we now trigger zoom scroll mode by click-and-hold (or touch-and-hold). https://bugzilla.gnome.org/show_bug.cgi?id=704703
* range: Remove dead assignmentBenjamin Otte2013-08-041-2/+0
|
* Deprecate and ignore the timeout-initial and timeout-repeat settingsWilliam Jon McCann2013-07-111-12/+4
|
* gtk: Use new macros for defining private dataEmmanuele Bassi2013-07-091-5/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=702996
* Deprecate and ignore gtk-keynav-cursor-only and gtk-keynav-wrap-aroundWilliam Jon McCann2013-06-261-37/+0
|
* range: don't draw origin when the slider is invisibleCosimo Cecchi2013-02-271-1/+1
| | | | | | | When the range of the GtkRange is zero (i.e. the upper and lower bounds of the adjustment have the same value), don't use an origin to draw the trough, as the slider will also be hidden, and the juncture between the two sections of the trough will be visible.
* Add gtk_widget_(un)register_windowAlexander Larsson2013-02-071-2/+2
| | | | | | | | | | | | 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
* range: don't trim the trough rectange by the trough marginCosimo Cecchi2013-01-141-12/+12
| | | | | | | | | | | | | | | Commit e32da246a84492f02b4dac5a448bb46cb23d68b8 made GtkRange's trough respect the CSS margin property, but it also trimmed the box in which the trough reacts to click events by the margin. We still want to catch events in that area instead, and just make sure the margin is applied when drawing (which was already implemented by that commit). This commit reverts the parts of e32da246a84492f02b4dac5a448bb46cb23d68b8 that didn't involve drawing, fixing the bug. https://bugzilla.gnome.org/show_bug.cgi?id=691677
* Implement gtk-primary-button-warps-slider GtkSettingKristian Rietveld2012-09-111-2/+18
| | | | | | Make GtkRange honor the setting and implement it in the quartz backend, it proxies the "click in the scroll bar to" property from the OS X PrefPane.
* range: read and use CSS margin values for the trough componentCosimo Cecchi2012-05-171-14/+29
| | | | | | | | | | | | Many themes want to render the trough background/stroke thinner than the full height/width (which is constructed around the value of the 'slider-width' style property). Read and apply the CSS margin from the theme on the trough component, so that themes can make it smaller at their will without the need to override the render_background, render_frame and render_activity methods of GtkThemingEngine. https://bugzilla.gnome.org/show_bug.cgi?id=676196
* range: remove commented out codeCosimo Cecchi2012-05-171-7/+0
| | | | | | | We wouldn't need any detail anyway, since we use a progressbar style class for the progress part of GtkRange. https://bugzilla.gnome.org/show_bug.cgi?id=676196
* Add a 'fine adjustment' mode to rangesMatthias Clasen2012-04-271-8/+34
| | | | | | | | | | | Shift-click in the slider now starts a drag in 'fine adjustment' mode, where we move the slider 10-times slower than the mouse. This can be very helpful when scrolling through a very long document or webpage, and moving the scrollbar even a single pixel already jumps too far in the content. https://bugzilla.gnome.org/show_bug.cgi?id=563688
* Change button bindings for range widgets aroundMatthias Clasen2012-04-271-7/+7
| | | | | | | | It seems to be general consensus that button 1 should do the jumping, so we now jump to the clicked position on primary button clicks and page on secondary button clicks. Touch behaves like primary. https://bugzilla.gnome.org/show_bug.cgi?id=563688
* gtk: Don't call gdk_window_process_updates() when scrollingBenjamin Otte2012-04-051-30/+0
| | | | | | | This can cause lagging when scrolling as it causes us to repaint on every scroll event. This wasn't historically a great problem, but with smooth scrolling we get a lot more events, so this now creates visible lagging on slower machines.
* Avoid infinite recursion when removing a grabMatthias Clasen2012-03-121-2/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=671819
* range: Straighten the wheel delta calculationMatthias Clasen2012-03-041-34/+17
| | | | | | | Scroll events report normalized deltas in terms of an abstract 'scroll unit' now, so our job is to determine a suitable scroll unit here. Since we are changing the value of the adjustment, the allocation of the widget does not factor into this at all.
* types: Move GtkAdustment declaration to gtktypes.hBenjamin Otte2012-03-031-6/+7
| | | | | ... and make all the headers to not include gtkadjustment.h anymore. Of course, also include it in the source files instead.
* range: Use the correct size for scalingMatthias Clasen2012-03-011-4/+10
| | | | | | When scaling the scroll delta, always use the 'large' dimension of a range widget. When dx was 0, the code code accidentally use the small dimension.
* gtk: Implement smooth scrolling in scrolledwindow/rangeMichael Natterer2012-03-011-16/+49
| | | | | | | | | | 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.
* range: Have slider jump to the pointer coordinates on touch devicesCarlos Garnacho2012-03-011-9/+14
| | | | | | This widget is too narrow to make touch interaction tricky enough, so don't add the penalty of having the slider run farther from the touch coordinates if it happens to miss the slider.
* range: Remove gtk-touchscreen-mode usageCarlos Garnacho2012-03-011-9/+5
| | | | | | Emulated crossing events with mode GDK_CROSSING_TOUCH_PRESS/RELEASE already cater dynamically for the "don't prelight on touch devices" usecase.
* Change FSF AddressJavier Jardón2012-02-271-3/+1
|
* range: Don't perform a GTK+ grabCarlos Garnacho2012-02-231-9/+5
| | | | | | The implicit grab on priv->event_window already warrants that this widget is the only one getting events while the button is pressed, so avoid the extra GTK+ grab here.
* Consistently private headersMatthias Clasen2012-02-141-1/+1
| | | | | Add a 'private' suffix to all newly introduced private headers.
* Allow context menus on scale slidersMatthias Clasen2012-02-141-0/+10
| | | | This will be used for a popup in the color chooser.
* Draw no trough for color scalesMatthias Clasen2012-02-141-9/+12
|
* gtkrange: Use symbolic names for button numbersCarlos Garcia Campos2012-01-271-10/+12
|
* GtkRange: fix resize-grip overlap handlingMatthias Clasen2012-01-141-1/+1
| | | | | We only want to shrink the scrollbar allocation by the actual overlap, not always by the full size of the resize grip.
* range: Use the widget state flags as a base for drawingRui Matos2012-01-091-38/+34
|
* Add has-origin property for GtkScaleAndrea Cimitan2011-12-141-29/+91
| | | | | | | | | | | If the scale has an origin (it will have one by default), GtkRange will render the two sides before/after the current value with different style classes, making it possible for themes to use different colors and properties for the two areas. This was possible in GTK 2 with style details, but got lost during the road to 3.0. https://bugzilla.gnome.org/show_bug.cgi?id=665140
* Drop uses of @returns syntaxMatthias Clasen2011-11-211-2/+3
|
* Add top/left/bottom/right style classes to steppersAlexander Larsson2011-11-171-0/+17
| | | | | This is needed for e.g. win32 theming, but is also generally useful.
* gtk: Fix compiler warnings from include fixesBenjamin Otte2011-11-161-0/+1
|
* Fix some implicit declaration warningsRico Tzschichholz2011-11-111-0/+1
| | | | There were some includes of gtkmain.h missing
* gtk: move _gtk_modules_has_mixed_deps() to gtkmodlesprivate.hMichael Natterer2011-10-231-1/+0
| | | | and remove gtkmainprivate.h completely.
* GtkRange: use the right widget for coordinate translationCosimo Cecchi2011-10-211-1/+1
| | | | | | | | | | | | GtkRange needs to check if its allocation intersects with the resize grip allocation (trimming its own allocation if it does). In order to do that, it needs to translate its allocation into window coordinates, and before that, find the window to whose the allocation is relative; code goes all the way finding the right parent widget, but then doesn't actually use it when translating the coordinates, leading to using the wrong rectangles for the intersection check. https://bugzilla.gnome.org/show_bug.cgi?id=662308
* Make focus rectangles optionalMatthias Clasen2011-08-101-1/+1
| | | | | | | | | | | | | | | | | | This commit introduces a new setting, gtk-visible-focus, backed by the Gtk/VisibleFocus X setting. Its three values control how focus rectangles are displayed. 'always' is equivalent to the traditional GTK+ behaviour of always rendering focus rectangles. 'never' does what it says, and is intended for keyboardless situations, e.g. tablets. 'automatic' hides focus rectangles initially, until the user interacts with the keyboard, at which point focus rectangles become visible. https://bugzilla.gnome.org/show_bug.cgi?id=649567
* Convert GailRange to GtkRangeAccessibleMatthias Clasen2011-07-051-0/+3
|
* GtkRangePrivate: Improve struct packingMatthias Clasen2011-04-121-3/+4
|
* range: allow stepper-spacing > 0 and trough-under-steppers = TRUECosimo Cecchi2011-03-161-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4bb3d6441439e4d99255a3a08b39da7100ced953 introduced a limitation to GtkRange style properties; when stepper-spacing is > 0, trough-under-steppers is automatically set to FALSE; this means that setting a spacing between the steppers (e.g. the scrollbar buttons) and the trough (i.e. the area over which the slider is free to move) would make the buttons always get the full allocation on the !orientation direction. The rationale is without this limitation, you would get an area which seems clickable, but it's actually not. While this is true, and undesirable, for big stepper spacings, themes that use trough-under-steppers (which is TRUE by default anyway), might want to set smaller spacings to avoid drawing a double line between the button and the slider borders. To add confusion, the documentation got it flipped, i.e. it stated setting a positive stepper-spacing would set trough-under-steppers to TRUE (which would also make the behavior expected by commit 4bb3d6441439e4d99255a3a08b39da7100ced953 impossible). I don't think hardcoding either of the two limitations is a good thing. We should let themes handle this instead, and remove this limitation. If you want the old behavior, you can manually set trough-under-steppers to FALSE if you set a positive stepper-spacing in your theme. https://bugzilla.gnome.org/show_bug.cgi?id=644777
* range: x and y coordinates of the arrow rendering should be doubleCosimo Cecchi2011-03-031-2/+2
| | | | To prevent off-by-one rounding errors when drawing them later.
* range: don't set junction sides on scrollbar steppersCosimo Cecchi2011-03-031-2/+8
|
* Minor documentation improvementsMurray Cumming2011-02-231-1/+1
| | | | Mostly correcting it's to its and changing some , to .
* Add gtkorientableprivate.h headerMatthias Clasen2011-01-301-1/+1
|
* Silence new gcc warningsMatthias Clasen2011-01-231-42/+38
| | | | | gcc 4.6.0 has started to warn about set-but-unused variables. So don't do that, then.
* [GI] Add missing (out) and (array) annotationsPavel Holejsovsky2011-01-201-3/+5
|
* Set horizontal/vertical style classes to GtkRangesCarlos Garnacho2011-01-191-0/+1
|
View Lorry Controller Status