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