GNOME Bugzilla – Bug 761416
GtkLevelBar offset values not behaving as expected
Last modified: 2016-02-29 20:51:22 UTC
Created attachment 320205 [details] levelbar offset test Example program attached. Using a discrete-mode levelbar, with offset values set at 2, 3, and 4, the lowest level offset is not used. Looking at the CSS classes in the inspector, a value of 1 has a class of "full", 2 is "medium", and 3-4 are "high". I would have expected 1 to be "low". If I add a call to levelbar.remove_offset_value("full"), 1-2 are "low", 3-4 are "high", and "medium" is skipped.
I'm similar behavior with 3.19.10. The levelbar with a value of 1 is green, indicating it is not using any of the offset classes. The other values appear to be correct: 2 is low/red, 3 is medium/orange, 4 is high/yellow.
full is a new class that I've added to address your previous concern. What is happening now is probably that you are not adjusting the full offset to the new max-value (only low and high), so the original value of full at 1.0 sticks around. In addition, medium is not actually one of the standard offsets that are covered by the theme. Here is what I would recommend: <child> <object class="GtkLevelBar"> <property name="visible">1</property> <property name="mode">discrete</property> <property name="max-value">4</property> <offsets> <offset name="low" value="2"/> <offset name="high" value="3"/> <offset name="full" value="4"/> </offsets> </object> </child> This gives a discrete level bar with 4 segments, which are - orange (low) if only one or two are filled - blue (high) if three are filled - green (full) if all 4 are filled
Thanks. If I just replace "high" with "full" in example I had attached, everything works fine. Maybe just documenting what offsets are set automatically would help?
Never mind, I was looking in the wrong version of the documentation. I see it now.