Am 06.12.2017 um 17:02 schrieb Tavmjong Bah:

The five solutions, from top to bottom, are:

* Custom Gtk::Range widget couple with Gtk::Spinbutton:
* Gtk::Scrollbar coupled with Gtk::Spinbutton:
* Gkt::ProgressBar coupled with Gtk::Spinbutton:
* Subclassed Gtk::Spinbutton:
* Gtk::Scale coupled with Gtk::Spinbutton:

It's a bit hard to make a founded statement based on partially unfinished implementation (I assume many of those I'd consider unusable in the current form could be made to work reasonably well with CSS or minor code changes) so I'll try to comment mostly on the underlying functional aspects (although that's hard too without having a closer look at the actual implementation)... Anyway:

While I appreciate (4) for the approach at achieving something compact it seems riddled with functional issues - besides the problem of the mouse being "catched" by the numerical input while working on the ProgressBar (and vice versa) the dynamic change of the ProgressBar's witdh causes the relative position to change abruptly as the total length changes (so this would need to be disabled).
Also the design is problematic (borders all around the ProgressBar - not sure how straightforward this would be to fix)
(2) might be OK if tuned with CSS but it lacks the "filling" effect of the slider, so not ideal in my opinion.
(5) looks solid, too (at least the CSS-tweaked version considering we want to add text) - questions would be: does it have any advantages over the remaining choices?
(1),(3) look identical when tweaked with CSS but if you say (3) is more difficult to implement I don't see a reason to use it.
(1) seems to work (in principle) nicely considering functionality. Obviously the "slow scrolling" needs to be fixed to start at the current value and I'd also prefer a different modifier - likely Ctrl) but apart from that I don't see any obvious issues.
However Design has some issues, for example I'd use use an arrow pointing up (but that's probably not important at this stage). What might be a more serious issue issue is the font rendering: For some reason the white font renders very badly. In your screenshots on Linux (where only grayscale anti-aliasing seems to be used) the text appears already really light and hard to read. On Windows (see attached), where subpixel anti-aliasing is used the text becomes even less legible (the anti-aliasing implementation might even be broken here). Maybe it can simply be tweaked away with CSS but maybe it's also a fundamental toolkit issue...

What I'm missing from all options:
I really liked the suggestion to re-use the current design but fix the existing issues, most prominently make the number input insensitive while manipulating the slider and require a single click (without dragging) to enable number input.
If I look at your designs all of them are made of less than 60% slider but over 40% of spinbutton. If I look into our toolboxes most of the sliders are only half as wide, though, which would result in about 20% slider (i.e. unusable) and 80% spinbutton (i.e. we could just drop the slider and use a spinbutton to start with). So *if* we want to continue using the proposed widgets in these places we still need to come up with a better design...

Best Regards;
Eduard