On Tue, 2017-12-12 at 20:09 +0100, Eduard Braun wrote:
Am 11.12.2017 um 13:35 schrieb Tavmjong Bah:
Hi all,
First, let me thank all of those who have given feedback! I've got an updated demo taking into account as much of the feedback as possible. A few of the changes:
- Shift replaces Alt to trigger slow-mo mode.
Any reason for preferring Shift to Ctrl? Personally I'd consider Ctrl more intuitive (i.e. if I even tried a modifier key to control functionality of a widget, it would be Ctrl, not Shift) and I think others felt the same way. I assume you have a reason, I just have not heard it yet (but you seem to avoid Ctrl by all means ;-) ).
No particular reason... I'll switch it to Ctrl (by popular demand).
- Slow-mo updating glitches fixed.
Partially confirmed. There is still an issue if one clicks into the slider (-> value jumps to cursor position), then holds down Shift and starts moving the mouse (-> value jumps back to old position).
I'll look into this...
- Order of drawing bar/text changed to give cleaner text.
Confirmed, much more legible now.
- Improved (and more realisitic styling).
Confirmed (with spinbutton.css) except for 4th and last option where the large margin/padding on top and bottom of the slider still look a bit strange.
One might think about making the background of the slider match the background of the numerical input (i.e. white) to achieve an overall more pleasing look; then again having a grayish background for the slider helps differentiate the slider area from the numerical input, so might not be a bad thing after all.
From my own experience and from feedback, I am inclined to replace the Gimp Spin Scale widget with the top-most option. This has a reasonable performance and relatively simple code (20% of the number of lines compared to gimpspinscale.c). The second from bottom is also quite nice (slow-mo mode is triggered by holding the mouse down without moving for a second; it has 10% of the number of lines compared to gimpspinscale.c).
I agree, the top one still seems to be the easiest to use. While UI of the of the second from bottom is OK, too (bullet hides the text, though) personally I don't get the slow-mo mode (same as with the second from top): When activating this mode there is still a small area "in the middle" that scrolls quickly when moving the mouse and moves around making it very unpredictable; when moving the mouse cursor far away it simply scrolls with continuous (very slow) speed.
What I'd still appreciate is some feedback on my earlier question: How do we intend to use this new spin slider widget? It obviously is not suitable as a direct replacement for the spin sliders we currently use in toolboxes due to the larger horizontal width requirement (the old widget was already too wide with gtk3/Adwaita). Do we drop the widget from these locations and use it only in the places were we have enough space available? Do we make the spin sliders wider (which would result in many controls becoming inaccessible if we do not require 21:9 screens)? Do we drop Adwaita and start "doing our own thing"?
The advantage of CSS is we don't need to drop Adwaita to do our own thing... we can override part of the Adwaita theme. I plan on making the +/- buttons narrow by default.
I've done a search through the GUI and have found that the GimpSpinButton occurs in the following places:
* Objects dialog:
Included via the SimpleFilterModifier widget.
Note: Opacity is handled by a hand-rolled Scale and SpinButton combo.
The SimpleFilterModifier widget should be replaced by the CompositeSetting widget which includes the SimpleFilterModifier widget and a SpinScale widget for opacity.
* Layers dialog:
Included via the CompositeSettings widget.
Note: There are two instances of the CompositeSettings widget here which is strange as the CompositeSettings widget can handle both.
* Fill-Stroke dialog:
Included via the CompositeSettings widget.
* Filter Effects:
Included in various primitive sections via the SpinScale and DualSpinScale widgets. The labels inside the GimpSpinScale widgets are left blank and instead are put in a separate label widget in front of the SpinScale and DualSpinScale widgets. This could be changed to save space.
BTW, There is a spin-slider widget that is still in our code base but hasn't been used since 0.48. It is what the filter effects used then.
I don't see any particular case where we are seriously space constrained but if necessary we can replace the SpinScale by a simple SpinButton.
Personally I don't see an easy option with the current designs. I actually tried to stack the +/- buttons again which could be realized with CSS (see the win32 theme for an example - you can select it from the "Visual" tab of the gtk inspector) but even then we still do not really gain enough space (and the gtk-devs were not wrong: the buttons become tiny). So maybe it's time to re-think spin slider widgets in toolboxes from the start and I'd say we should brainstorm this before finalizing on any design, otherwise we might just need to start over again once we realize the new widget did not gain us anything except a GPLv2+ licensing...
I would be happy to entertain a better solution but in the meantime I'll go ahead with replacing the GimpSpinScale widget now. While it may not be an optimal solution, it is better than what is there now.
Tav
Best Regards, Eduard