On Mon, 2017-12-04 at 13:27 +0000, Mark Crutch wrote: My toy implementation removed the overlap... much easier to use. Sounds reasonable. I'll try to implement.

Am 04.12.2017 um 15:07 schrieb Maren Hachmann: Interesting, looks completely different than what I have (which is - I guess - stock Adwaita), see attachement. Looks quite clear - but also uses about twice the space :-/ Regards, Eduard

On Mon, 2017-12-04 at 22:54 +0100, Maren Hachmann wrote: Maybe it's theme dependent. What's the theme Ubuntu uses?

On 04.12.2017 13:53, Tavmjong Bah wrote: This is very valuable, as the width of the slider is critical for efficient use and an external label would be "dead" space. I played with such designs in mockups a few times. Example attached. It's part of a series where the colors where meant to signify minimum, negative range, exact zero, positive range or maximum. Note that I reduced the gap between labels and values to ease scanning. This at the cost that activating numerical editing may require a double or modifier-click. Please don't call it a progress bar; it's a slider and the part of it that signifies the value could be called value bar or maybe indicator There are a few cases to handle: - fast and course adjustments - fine and slow - small steps - precise input (numerical entry) Because of this, I think it is a worthwhile idea to handle both fast-and-coarse and fine-and-slow adjusting in a discoverable manner, no modifiers used. After all, I spend quite some time trying to come up with a good way to do just that. See https://thorwil.wordpress.com/2007/05/01/fan-sliders/ (which I am not saying is a solution, here). One inspiration was the astonishingly complex ladder widget in Houdini: http://www.sidefx.com/docs/houdini/basics/ladder Of course that thing exists because value ranges can be huge and fine-grained in their consequences in that application. Having 2 ways of adjusting available without modifier is nice, but it seems the GIMP widget is often misunderstood. Upper edge is used for setting the value to where the pointer is. A jump; only then do you have a 1:1 relation between movement and value change. Both halves suffer from the delays when the value bar is not updated until the effect of the change has been rendered. I understand why it's done that way, but have to note that it makes hitting a desired value-range harder. I might prefer some pulsing/blinking or indicating both previous value and soon-to-be value, instead. That's a non-issue for the lower half, as it doesn't matter from where you start a slide and you have plenty of area to just do that. For the upper area, the user has to figure out that they have to click to the left of the numbers and do a drag, in order to reach that part of the range. That is rather bad. Ways to deal with the slider vs numerical input issue: - trigger input only on the lower half, allow click-jump on the entire upper half. - Put the label unto the slider, but keep the numbers outside. - Use a narrow button to the right of the main widget, as sole mean to go into numerical input. - Interpret numbers and arrow keys as input as soon as the pointer hovers the widget (incompatible with pen and touch). - Activate numerical input only on double-click or some modifier-click. - Use the upper half for 1:1 adjustment, but without jump-to-pointer. Offer an alternative jump action, e.g. on middle-click. Yes. Maybe. Yes. Aside of 1:1 drag, a fine adjustment could be on Ctrl-drag and jump-to-pointer on middle-click. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/