And reset the grab_location in the ::released handler of the multipress
gesture.
Previously, when leaving fine-tune mode, the ::released handler of the
multipress gesture would call stop_scrolling, which calls
range_grab_remove and resets the grab_location. The ::drag-end handler
is executed after that, and only unsets priv->in_drag if the
grab_location is MOUSE_OUTSIDE, which it never was, since the ::released
handler already reset it. This lead to priv->in_drag being set even
though no dragging was in progress anymore, which e.g. made shift
pressed after leaving the fine-tune mode entering it again.
https://bugzilla.gnome.org/show_bug.cgi?id=761402
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
Use G_PARAM_DEPRECATED with deprecated style properties.
This will make it easier to identify and remove such stale
properties from css, since it will now trigger warnings.
The introduction of the trough node was not properly carried
into the code constructing stepper nodes, and was causing
assertion failures there. This was only showing up on Windows,
since Adwaita and HighContrast don't have steppers.
We were not queuing a draw (and not updating the CSS node) when
the slider visibility changed. This was exposed by the Trough
button in tests/testscale.
Fix this by taking slider visibility into account when deciding
whether to queue a draw in response to adjustment changes.
Change things around so that warp-to-click and jump-by-pages are
bound to left-click and shift-left-click, depending on the value
of gtk-primary-button-warps-slider. Autoscrolling is bound to
right-click.
To achieve this, reorganize gtk_range_multipress_gesture_pressed
so that the functions are clearly separated.
Make shift right-click on the trough start autoscrolling. The
autoscrolling is similar to the way steppers operate now, with
the difference that we vary the scrolling speed based on the
distance of the pointer from the widget.
Clicking on steppers does different things depending on which
button you use. We used to scroll to the end on secondary click
and use high-speed autoscrolling on middle-click. Switch these
two around, since the scroll-to-end functionality is less likely
to be useful, and the seconary button makes the autoscrolling
more easily available.
The calculation to update the initial slider position on zoom
changes was not working correctly when using keys to toggle
zoom on and off for scales. Avoid it by updating the position
beforehand.
Moving the mouse while pressing one of the steppers was making
the slider jump to the end, unexpectedly. This was caused by the
drag gesture kicking in when it shouldn't. Fix this by making
all drag gesture signal handlers only do something if we are in
a drag thats started on the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=751050
The direction in which the slider moves can be inverted by setting the
inverted property. But the draw method does not check this, instead it
checks if the direction of the widget is set to be right to left.
Call the should_invert function in order to determine if the direction
of the range should be inverted. It too checks the widget's direction,
but also checks the "inverted" property, and allows the range to be
drawn inverted even if it is vertically oriented.
https://bugzilla.gnome.org/show_bug.cgi?id=746712
Compute the proportion of the range that should be filled to match the
fill level, and use it to compute the starting point and length of the
area between the slider and the fill level.
https://bugzilla.gnome.org/show_bug.cgi?id=734741
As Sebastian pointed out, just resetting the initial slider
position was an incomplete fix, because it does not cause the
delta to be recomputed, which is important in this scenario,
because you've likely travelled some distance over the slider
before the long press kicks in.
Instead, explicitly record both the slider position and the
delta.
We record the starting position on button press, but only
start the zoom mode when the long press timeout kicks in.
Depending on circumstances, this can cause a noticable jump.
Avoid this by resetting the recorded starting position after
the long press timeout. Suggested by Sebastian Keller.
The adjustment value being equal is checked by
gtk_adjustment_set_value() and the necessity of calc_layout() is handled
by the value_changed signal handler.
Css margin now works on the slider as they do on the trough.
The margin is not considered in the space allocation as it is for
the trough, so the slider width will be the set slider-width -
margins. Spefifying margins on the main widget in the css will
clearly affect both the trough and the slider, so theme changes are
needed.
This will be used to identify a scrollbar is being dragged - we
don't actually need the style class; another way to keep track
of the dragging status would be ok too.
The scale in the selectable listbox in page 2 of gtk3-widget-factory
has the flaw that the row is getting selected even when one only
interacts with the scale - unlike e.g. the checkbutton and button
further down in the listbox.
The problem is that GtkRange is trying to claim the sequence for
the drag gesture from the ::pressed handler of a multipress
gesture. Since the drag gesture hasn't seen the sequence at this
point, that is ineffective.
The fix here is to rearrange the gestures so that the multipress
gesture sees the sequence before the drag gesture, and then
claim the sequence from the ::drag-begin handler.
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
... in places where we draw a background. This was changed for GTK 3.0.0
to allow animations, but these days it doesn't make sense anymore to use
gtk_render_activity() for backgrounds.
That gesture is meant to handle clicks from several buttons, so unset
the new GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
If the drag gesture gets a GtkGesture::updated signal, the user
is directly interacting through pointer/touch with the range slider,
animating the adjustment value change in this situation can produce
perceived lag, so set the value immediately when this is happening.
Resize grips were introduced for GNOME 3.0, before we had any of the
"new GNOME app" features like invisible borders and CSD. With OS X 10.6
and 10.7, Apple has replaced the classic grips in their applications
with invisible borders as well.
New GNOME app designs don't use resize grips anymore and the new
default theme for GTK+, Adwaita, disables them entirely by forcing their
width and height to 0.
They're past their time. Remove the code to support them. This can
always be reverted if some app relies on them.
A multipress gesture takes care of clicks, and where those happened.
If the click is meant to move the slider while pressed, the drag gesture
takes over, dragging the slider while active.
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.
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.
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.
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
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
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.
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
Commit e32da246a8 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
e32da246a8 that didn't involve drawing,
fixing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=691677
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
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
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
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.
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.
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.
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.
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.
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
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
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
Commit 4bb3d64414 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
4bb3d64414 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
GtkFileChooserDefault watches the toplevel and montitors "set-focus"
signal on it... however the connection needs to be remade when the
GtkFileChooserDialog is in an embedded toplevel.
Measure's taken: GtkWindow propagates hierarchy changes when
_gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
unsets the widget's parent window earlier in the function so that
the possible hierarchy change is still able to properly access the hierarchy.
GtkFileChooserDefault checks if the "new" toplevel is indeed
gtk_widget_is_toplevel() but not the old one, GtkRange has been
updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
vfunc, other classes already do this properly.
We need to be a little more careful when determining the overlap
between the new allocation and the grip area. This was causing
vertical scrollbars in evince to overlap with the grip.
If there are both horizontal and vertical scrollbars, there is
an unused 'corner' into which the resize grip fits. Individual
scrollbars need to be shortened and moved to make room for the
resize grip.
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.
This was a style property to let theme engines 'opt-in' to more
correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct
behaviour.
This was a style property to let theme engines 'opt-in' to more
correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct
behaviour.
This was a style property to let theme engines 'opt-in' to more
correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct
behaviour.
As usual, this is protected by a style property:
GtkRange::stepper-position-details
The detail strings are
<detail>_start, <detail>_end and <detail>_middle.
See bug 621250
In the early 2.14.x releases, GtkAdjustment was changed to enforce
that values are restricted to the range [lower, upper - page_size].
This has always been the documented behaviour, and the recommended
practice is to set page_size to 0 when using adjustments for simple
scalar values, like in a slider or spin button.
Due to the large number of applications that are affected by this
change, the behaviour has been reverted to the old behaviour in
2.14.3, with an explicit warning that this change will be
reintroduced in 2.90.
This reverts commit e6373738fc.
https://bugzilla.gnome.org/show_bug.cgi?id=619474
* gtk/gtkrange.c: (gtk_range_adjustment_value_change):
Queue the draw also if the range is a scale and the value is drawn,
fixing bug #533946 (Markus Brinkmann), when two HScales use one
adjustment.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
Add accessors for range->range_rect, range->slider_range,
range->slider_size_fixed and range->min_slider_size. Didn't add
properties for any of them because thir purpose is mostly to enable
proper subclassing.
2009-02-25 Xan Lopez <xan@gnome.org>
Bug 495320 - GtkRange does not use gdk_event_request_motions
* gtk/gtkrange.c:
(gtk_range_motion_notify): Use gdk_event_request_motions to
request more motion events, as suggested in the docs for widgets
using motion hints.
svn path=/trunk/; revision=22407
2009-01-26 Bastien Nocera <hadess@hadess.net>
Bug 569240 - Crasher when using markers
* gtk/gtkrange.c (gtk_range_destroy): Avoid crashes when destroying
a GtkRange with markers
svn path=/trunk/; revision=22224
Bug 565656 – Add marks to scales
* gtk/gtkrange.[hc]: Add internal api to define 'stop values'
that have a little resistance when dragging the slider over it.
* gtk/gtk.symbols:
* gtk/gtkscale.[hc] (gtk_scale_add_mark): New function to add
a 'mark' to a scale, which will draws a tick, plus optionally
some text, and makes the value a stop value.
(gtk_scale_clear_values): Removes all marks.
* tests/testscale.c: Test for marks on scales
* tests/Makefile.am: Integrate it
svn path=/trunk/; revision=22149
2008-11-11 Michael Natterer <mitch@imendio.com>
Bug 553765 – Add orientation API to GtkRange
* gtk/gtkrange.[ch]: implement the GtkOrientable interface. Add
evil code that makes sure that the stepper_detail and slider_detail
set in GtkRangeClass continue to work with the hacked subclasses
below.
* gtk/gtkscale.[ch]: swallow all code from GtkHScale and GtkVScale
and add gtk_scale_new() and gtk_scale_new_with_range() which take
a GtkOrientation argument. Set slider_detail to "Xscale" so above
evil code works.
* gtk/gtkscrollbar.[ch]: add gtk_scrollbar_new() which takes a
GtkOrientation argument. Set stepper_detail to "Xscrollbar" so
above evil code works.
* gtk/gtkhscale.c
* gtk/gtkvscale.c
* gtk/gtkhscrollbar.c
* gtk/gtkvscrollbar.c: remove all code except the constructor and
call gtk_orientable_set_orientation() in init().
* gtk/gtk.symbols: changed accordingly.
svn path=/trunk/; revision=21779
2008-08-12 Michael Natterer <mitch@imendio.com>
* gtk/*.c: consistently chain up using
GTK_FOO_CLASS(parent_class)->bar(instance) instead of
(*GTK_FOO_CLASS(parent_class))->bar(instance).
svn path=/trunk/; revision=21085
2008-08-06 Michael Natterer <mitch@imendio.com>
* gtk/gtkcombobox.c
* gtk/gtkiconview.c
* gtk/gtkrange.c
* gtk/gtkscrolledwindow.c
* gtk/gtktreeview.c: remove CLAMPing from values passed to
gtk_adjustment_set_value() since it does it right now.
svn path=/trunk/; revision=21021
2008-08-02 Matthias Clasen <mclasen@redhat.com>
Bug 429427 – Add "arrow-spacing" style property to GtkRange
* gtk/gtkrange.c: Add an arrow-spacing style property.
Patch by Carlos Garnacho and Christian Dywan
svn path=/trunk/; revision=20939
2008-06-30 Cody Russell <bratsche@gnome.org>
* Practically everything changed.
Change all references of GIMP Toolkit (and variations of it)
to GTK+ Toolkit, showing no mercy at all to our beloved
ancestry. (#540529)
svn path=/trunk/; revision=20709
2007-09-06 13:37:28 Tim Janik <timj@imendio.com>
* gtk/gtkrange.c (gtk_range_adjustment_value_changed): removed code
that forced range repaints upon every motion event, because these tend
to stall other repaints on busy CPUs.
added a timer to still force repaints every once in a while (roughly
5Hz atm) to avoid leaving the user without feedback on the range.
fixes bug #460534.
svn path=/trunk/; revision=18730
2007-01-16 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkrange.c (range_grab_remove): Queue a redraw when the
grab changes. (#396470, Benjamin Berg)
svn path=/trunk/; revision=17159
2006-11-16 Michael Natterer <mitch@imendio.com>
Add new infrastructure for notifications of failed keyboard
navigation and navigation with restricted set of keys.
The patch handles configurable beeping, navigating the GUI with
cursor keys only (as in phone environments), and configurable
wrap-around. Fixes bugs #322640, #70986, #318827, #334726, #334742
and #309291.
* gtk/gtksettings.c: added properties gtk-keynav-cursor-only,
gtk-keynav-wrap-around and gtk-error-bell.
* gtk/gtkwidget.[ch]: added new signal "keynav-failed" and public
API to emit it. Added New function gtk_widget_error_bell() which
looks at the gtk-error-bell setting and calls gdk_window_beep()
accordingly.
* gtk/gtk.symbols: add the new widget symbols.
* gtk/gtkcellrendereraccel.c
* gtk/gtkimcontextsimple.c
* gtk/gtkmenu.c
* gtk/gtknotebook.c: use gtk_widget_error_bell() or look at the
gtk-error-bell setting instead of calling gdk_display_beep()
unconditionally.
* gtk/gtkcombobox.c
* gtk/gtkentry.c
* gtk/gtkiconview.c
* gtk/gtklabel.c
* gtk/gtkmenushell.c
* gtk/gtkspinbutton.c
* gtk/gtktextview.c
* gtk/gtktreeview.c: call gtk_widget_error_bell() on failed keynav.
* gtk/gtkentry.c
* gtk/gtklabel.c
* gtk/gtkrange.c
* gtk/gtktextview.c: consult gtk_widget_keynav_failed() on failed
cursor navigation and leave the widget if it returns FALSE.
* gtk/gtkmenushell.c
* gtk/gtknotebook.c: only wrap around if gtk-keynav-wrap-around
is TRUE.
* gtk/gtkradiobutton.c: ask gtk_widget_keynav_failed() to decide
whether to to wrap-around, and don't select active items on cursor
navigation if gtk-keynav-cursor-only is TRUE. Should look at
gtk-keynav-wrap-around too, will look into that.
2006-11-15 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.[ch]: added properties "fill-level",
"show-fill-level" and "restrict-to-fill-level" and getters/setters
for them. The "fill level" is an additional marker on the range's
trough than can be e.g. used to indicate the amount of
pre-buffering in a range showing the play position of streamed
media. See the embedded API docs for details. Made GtkRangeLayout
a GTypeInstance private struct and removed finalize()
implementation. Fixes bug #349808
* gtk/gtk.symbols: added the new symbols.
2006-10-30 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c (gtk_range_key_press): consume the Escape key
only if we actually cancel a drag. Fixes bug #58389.
2006-07-18 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c: remember the sensitivity of the steppers in
GtkRangeLayout, update it in gtk_range_calc_layout() and check for
changes in layout_changed(), so adjustment changes that leave the
slider position unchanged are still able to update the steppers'
sensitivity. Fixes bug #347902.
2006-06-09 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c: added new style properties "trough-side-details"
and "draw-trough-under-steppers" and fixed the "stepper-spacing"
style property. Fixes bugs #342339 and #342249.
"draw-trough-under-steppers", when set to FALSE, starts trough
drawing next to the steppers instead of drawing the trough "below"
(around) the steppers. If "stepper-spacing" is set to any value
larger than zero, "draw-trough-under-steppers" is set to FALSE
automatically to avoid rendering an area that looks clickable but
isn't.
(gtk_range_calc_layout): honor draw-trough-under-steppers.
Don't reserve stepper-spacing on sides of the range that don't
have steppers.
(gtk_range_expose): changed drawing accordingly. Implement
"trough-side-details" which enables drawing of the upper and lower
parts of the trough with different details. This is useful for
theme engines which want to draw these parts differently.
(coord_to_value): correctly take all rendering options into
account. stepper-spacing > 0 caused jumping and otherwise
strangely behaving ranges before.
(other functions): changed accordingly.
2006-05-18 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c: canonicalize the name of the "activate-slider"
style property and use GTK_PARAM_READABLE instead of
G_PARAM_READABLE. Moved one "activate_slider" variable to the
local scope its used in.
2006-03-10 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkrange.c: Add a style property ::activate_slider that
allows themes to draw the slider active while dragged. (#311992,
Benjamin Berg)
* gtk/gtkcolorsel.c (gtk_color_selection_init): Fix two labels.
2006-03-09 Ross Burton <ross@openedhand.com>
* gtk/gtkwidget.c:
* gtk/gtkrange.c:
* gtk/gtktogglebutton.c:
Turn off prelighting when gtk-touchscreen-mode is enabled (#135666)
2005-11-22 Michael Natterer <mitch@imendio.com>
Made button-press timeouts which work like key repeat timeouts
configurable. Addresses bug #142582:
* gtk/gtksettings.c: added properties "gtk-timeout-initial" and
"gtk-timeout-repeat" which defalt to 200/20 (ms).
Use the values from GtkSettings instead of hardcoding them
(the repeat value is either taken as-is for fast repeat or
multiplied by 5 for slow repeat). Changed all places to use these
two standard initial/repeat timings:
* gtk/gtkcalendar.c (unchanged 200/20)
* gtk/gtknotebook.c (unchanged 200/100)
* gtk/gtkpathbar.c (changed from 300/150 to 200/100)
* gtk/gtkrange.c (changed from 250/100 to 200/100)
* gtk/gtkspinbutton.c (unchanged 200/20)
2005-11-11 Michael Natterer <mitch@imendio.com>
Added per-stepper API for GtkRange's stepper sensitivity as
discussed in bug #321056:
* gtk/gtkenums.h: added GtkSensitivityType which can be
{ AUTO, ON, OFF }.
* gtk/gtkrange.[ch]: added properties "lower-stepper-sensitivity"
and "upper-stepper-sensitivity" and public getters/setters for
them. Changed stepper drawing to honor the new properties.
* gtk/gtk.symbols: added the new symbols.
Wed Nov 9 16:29:42 2005 Tim Janik <timj@imendio.com>
* gtk/gtkrange.c: patch from maemo-gtk that changes GtkRange
to render its arrows insensitive when the adjustment is in
its min or max position. this makes range arrow behaviour
consistent with spin button behaviour. (#321056)
2005-09-01 Matthias Clasen <mclasen@redhat.com>
* gdk/*.c: Intern some more strings.
* gtk/gtkintl.h:
* gtk/*.c: Define an I_() macro and use it instead of the
bulky g_intern_static_string().
2005-08-31 Matthias Clasen <mclasen@redhat.com>
* gdk/Makefile.am:
* gtk/Makefile.am: Intern type names in code generated by
glib-mkenums, too.
* gtk/*.c:
* gdk/x11/*.c:
* gdk/*.c: Intern type names before registering the type to avoid
unnecessary copies.
2005-08-20 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkrange.c (gtk_range_adjustment_changed)
(gtk_range_adjustment_value_changed): Don't queue a draw
if the layout has not changed. (#313991, Benjamin Berg)
2005-03-21 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkprivate.h: Define macros GTK_PARAM_READABLE,
GTK_PARAM_WRITABLE, GTK_PARAM_READWRITE which are like
their G_ counterparts, but also mark the name, nick
and blurb as static.
* gtk/*.c: Mark param spec strings as static, using
the new macros.
2005-03-20 Matthias Clasen <mclasen@redhat.com>
Make PLT-reduction work with gcc4, and don't include
everything in gdkalias.h:
* gtk/grk.symbols: Group symbols by header and source file.
* gtk/makegtkalias.pl: Protect definitions by the same
preprocessor symbols used to guard the headers. Move
the alias declarations to a separate file which is
produced when calling makegtkalias.pl -def
* gdk/Makefile.am (gtkaliasdef.c): Add a rule to generate
this file.
* gtk/*.c: Include gtkalias.h after the other headers,
include gtkaliasdef.c at the bottom.
* gtk/*.h: Small cleanups.
2004-11-09 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkrange.c (gtk_range_real_change_value): Make
power a double.
(gtk_range_class_init): s/digits/decimal digits/ in doc
comment.
2004-10-06 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkrange.c (gtk_range_real_change_value): Replace a really
gross way of rounding to a specified number of digits. (#145232,
Peter Zelezny, patch by Soeren Sandmann)
