After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 511470 - Enable setting the origin point of the fill level
Enable setting the origin point of the fill level
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkRange
2.12.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-01-23 07:28 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2018-05-02 14:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stefan Sauer (gstreamer, gtkdoc dev) 2008-01-23 07:28:41 UTC
Some themes like clearlooks, clearlooks classic, darkilouche, ... draw a colored bar inside the GtkRange from the left to the slider position. I have a panorama position slider in my music application. The underlying GtkAdjustment goes from -1.0 to 1.0 (left to right). There this color bar looks really odd. Unfortunately the GtkAdjustment has no default/middle value.

If the theme wants to draw this, what about this:
min,max are positive, start from left
min,max are negative, start from right
min,max  have different signs, start from 0.0

invert everything for RTL languagages, and do simmilar for vertical ranges.
Comment 1 Benjamin Berg 2008-01-23 11:50:14 UTC
* min,max are positive, start from left
The default

* min,max are negative, start from right
You can set the "inverted" property of GtkRange to achieve this

* min,max  have different signs, start from 0.0
OK, no way to do this, but it would need to be handled on the GTK+ level somehow. I wonder if there are a lot of cases where this makes sense, or if it would make more sense to just hide the colored bar entirely in some cases.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2008-01-23 12:33:27 UTC
Agreed, even hiding the color bar would make sense in the third case.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2009-01-07 15:10:23 UTC
Matthias Clasen was saying in this mail that themes can actually get the adjustments from the widget:
http://mail.gnome.org/archives/gtk-devel-list/2009-January/msg00027.html

I'll probably try to disable the GtkRange::trough-side-details in my rc file. Not that nice, as it makes things looking inconsistent.
Comment 4 Matthias Clasen 2009-01-07 15:35:33 UTC
See bug 565144 for an example of how to do the trough-side-details thing programmatically for an individual scale.
Comment 5 Daniel Boles 2017-03-03 14:23:22 UTC
(In reply to Benjamin Berg from comment #1)
> * min,max are negative, start from right
> You can set the "inverted" property of GtkRange to achieve this

Won't that also swap the min/max? That just swaps the problem for another, if so.


> * min,max  have different signs, start from 0.0
> OK, no way to do this, but it would need to be handled on the GTK+ level
> somehow. I wonder if there are a lot of cases where this makes sense, or if
> it would make more sense to just hide the colored bar entirely in some cases.

Yeah, in these cases, I just have to turn off showing the fill level. I would like a way to show it from zero, though, or even a freely configurable value. I opened a similar ticket, which I'll probably close as a dupe soon.
Comment 6 GNOME Infrastructure Team 2018-05-02 14:31:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/288.