Spin slider widget: Opinions needed!

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Spin slider widget: Opinions needed!

Tavmjong Bah

Hi,

I've been looking into replacing the Gimp Spin Slider widget (e.g
Blur/Opacity in the Fill and Stroke dialog). The widget is licensed
under GPLv3 and is the only reason Inkscape as a whole is licensed
under GPLv3 rather GPLv2.. The board sometime ago agree that being a
GPLv2 program was desirable (I don't remember the exact reasoning).

A normal Gtk Spin Slider (aka Gtk::SpinButton) has an option to show
the "progress" of slider, that is the percentage (defined in some
arbitrary way) between a minimum and maximum value. This in Gtk 2 is
shown as a solid blue bar with width proportional to the value that
covers the widget from top to bottom. In Gtk 3 the solid blue bar is
replaced by a thin blue bar at the bottom of the widget.

As far as I can tell, the Gimp version of the slider makes three
changes:

1. It allows for a label inside the widget. This is a nice space saving
feature. The widget handles changing the label text from black to white
as the progress bar moves across the label.

2. It allows for a non-uniform scale by adding a "gamma" factor.

3. It adds the ability to drag the progress bar to change the value. If
one drags from the top (down arrow cursor) the change follows the
cursor directly. If one drags along the bottom half (double headed
cursor) the change is finer and relative to the current value.

I've always found that dragging the progress bar to be a bit awkward.
One problem is that one can not start the drag at the far right of the
widget as that area is reserved for typing a value directly in. Also,
the different functionality of starting the drag in the top of the
widget vs. the bottom of the widget is confusing.

Since I am rewriting this widget, I can adjust it to what people want:

* Do you want the progress bar?

* If so, should it be the full height of the widget (quite a bit more
complicated)?

* Do you want to be able to drag the bar? With one/two methods?

* Any other changes?

Thanks,

Tav


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Mark Crutch-2
As I understand it, one reason for the design of the Gimp spinbox is to make it easier to use with a graphics tablet stylus - hence the dragging of the bar. Personally I find it awkward to use whether with a mouse or a stylus, and particularly dislike the problems with dragging from the right that you mentioned. As for accidentally setting blur to 100% when trying to focus the text at the right... that's the bane of my Inkscape life! I would love to see them replaced with something else.


* Do you want the progress bar?

I do like the presence of the progress bar. It provides immediate feedback that plain numbers don't. If the box says 9, is that 9 out of 10 or 9 out of 100? A progress bar immediately gives you a sense of scale.
 
 
* If so, should it be the full height of the widget (quite a bit more
complicated)?

I don't necessarily think it should be full height, but it should be clear and obvious. It should also be clear that it's a progress bar, not an underline or other decoration - so perhaps also ensure the "unfilled" portion of the bar is visible.
 

* Do you want to be able to drag the bar? With one/two methods?

Dragging the bar is a nice feature which makes the widget a lot more immediate to use - great for just playing around.

I don't like the current two-method implementation, as I often end up activating the wrong one. That said, there are definite advantages to allowing both coarse and fine control. Perhaps some other approach could be used to still provide that capability - here are some possibilities off the top of my head:

* Make the amount of change proportional to the speed of the pointer movement, so that fast drags make coarse changes, whilst slow drags provide fine adjustment.

* Once the mouse button is held down, use left/right movements for coarse and up/down movements for fine adjustments.

* Left mouse button for coarse changes, right for fine. (Perhaps not so great for tablet users)

 
* Any other changes?

* One great feature in many Inkscape spinboxes is the context menu to let you select from a list of pre-defined values. The Gimp spinboxes lack these. Ideally I'm sure you would want a means for the developer to provide specific values (with comments), but having a standard fallback that lists, say, 10 evenly spaced values would be useful.

* The ability to do basic maths in Inkscape spinboxes is another useful feature that the Gimp ones lack.

* Mousewheel support almost goes without saying. But I'm saying it anyway, just in case ;)

* When dragging with the left button, clicking the right one should cancel the change and revert back to the previous value.



Regards,

Mark



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Maren Hachmann
In reply to this post by Tavmjong Bah
Hi Tav,

oh, I never noticed the two different modes... lol. I've always found it
annoying that it is so hard to set values in 0.1 steps, which I needed
frequently (my blurred objects are usually small, such as shadows behind
a text) - while it has already been possible.

I've always thought I had to use the numeric entry field for that
fine-tuning (and found that field pretty annoying, when I accidentally
clicked too much to the left and got 100% blur, taking long to render
and freezing Inkscape for some time before I can continue to work).
Having that field outside the slider would be useful.

Perhaps if scrolling with mouse-wheel meant 'fine-tune', dragging meant
'quick change' and clicking meant 'here', that could be good?

Currently, that thin strip of a bar is indeed difficult to see. It
doesn't necessarily need to fill the whole height, but a little more
height would make it easier on the eyes - the bars are really tiny
already. (Screenshot attached for those who don't have a copy of the
current development version installed)

Can you post a screenshot or gif of the default widget with /without
progress bar?

Maren

P.S.: and can someone fix the filter area in master before anyone thinks
of releasing 0.93? It's much too small and cuts off parts of the object,
making blur kind of useless to non-experienced users, when they would
always need to fix the area in the filter editor...

Am 04.12.2017 um 13:53 schrieb Tavmjong Bah:

>
> Hi,
>
> I've been looking into replacing the Gimp Spin Slider widget (e.g
> Blur/Opacity in the Fill and Stroke dialog). The widget is licensed
> under GPLv3 and is the only reason Inkscape as a whole is licensed
> under GPLv3 rather GPLv2.. The board sometime ago agree that being a
> GPLv2 program was desirable (I don't remember the exact reasoning).
>
> A normal Gtk Spin Slider (aka Gtk::SpinButton) has an option to show
> the "progress" of slider, that is the percentage (defined in some
> arbitrary way) between a minimum and maximum value. This in Gtk 2 is
> shown as a solid blue bar with width proportional to the value that
> covers the widget from top to bottom. In Gtk 3 the solid blue bar is
> replaced by a thin blue bar at the bottom of the widget.
>
> As far as I can tell, the Gimp version of the slider makes three
> changes:
>
> 1. It allows for a label inside the widget. This is a nice space saving
> feature. The widget handles changing the label text from black to white
> as the progress bar moves across the label.
>
> 2. It allows for a non-uniform scale by adding a "gamma" factor.
>
> 3. It adds the ability to drag the progress bar to change the value. If
> one drags from the top (down arrow cursor) the change follows the
> cursor directly. If one drags along the bottom half (double headed
> cursor) the change is finer and relative to the current value.
>
> I've always found that dragging the progress bar to be a bit awkward.
> One problem is that one can not start the drag at the far right of the
> widget as that area is reserved for typing a value directly in. Also,
> the different functionality of starting the drag in the top of the
> widget vs. the bottom of the widget is confusing.
>
> Since I am rewriting this widget, I can adjust it to what people want:
>
> * Do you want the progress bar?
>
> * If so, should it be the full height of the widget (quite a bit more
> complicated)?
>
> * Do you want to be able to drag the bar? With one/two methods?
>
> * Any other changes?
>
> Thanks,
>
> Tav
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-user
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user

Bildschirmfoto_2017-12-04_14-48-55.png (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Tavmjong Bah
In reply to this post by Mark Crutch-2
On Mon, 2017-12-04 at 13:27 +0000, Mark Crutch wrote:
As I understand it, one reason for the design of the Gimp spinbox is to make it easier to use with a graphics tablet stylus - hence the dragging of the bar. Personally I find it awkward to use whether with a mouse or a stylus, and particularly dislike the problems with dragging from the right that you mentioned. As for accidentally setting blur to 100% when trying to focus the text at the right... that's the bane of my Inkscape life! I would love to see them replaced with something else.


My toy implementation removed the overlap... much easier to use.

 * Do you want the progress bar?

I do like the presence of the progress bar. It provides immediate feedback that plain numbers don't. If the box says 9, is that 9 out of 10 or 9 out of 100? A progress bar immediately gives you a sense of scale.
 
 
* If so, should it be the full height of the widget (quite a bit more
complicated)?

I don't necessarily think it should be full height, but it should be clear and obvious. It should also be clear that it's a progress bar, not an underline or other decoration - so perhaps also ensure the "unfilled" portion of the bar is visible.
 

* Do you want to be able to drag the bar? With one/two methods?

Dragging the bar is a nice feature which makes the widget a lot more immediate to use - great for just playing around.

I don't like the current two-method implementation, as I often end up activating the wrong one. That said, there are definite advantages to allowing both coarse and fine control. Perhaps some other approach could be used to still provide that capability - here are some possibilities off the top of my head:

* Make the amount of change proportional to the speed of the pointer movement, so that fast drags make coarse changes, whilst slow drags provide fine adjustment.

* Once the mouse button is held down, use left/right movements for coarse and up/down movements for fine adjustments.


Sounds reasonable. I'll try to implement.

* Left mouse button for coarse changes, right for fine. (Perhaps not so great for tablet users)

 
* Any other changes?

* One great feature in many Inkscape spinboxes is the context menu to let you select from a list of pre-defined values. The Gimp spinboxes lack these. Ideally I'm sure you would want a means for the developer to provide specific values (with comments), but having a standard fallback that lists, say, 10 evenly spaced values would be useful.

* The ability to do basic maths in Inkscape spinboxes is another useful feature that the Gimp ones lack.

* Mousewheel support almost goes without saying. But I'm saying it anyway, just in case ;)

* When dragging with the left button, clicking the right one should cancel the change and revert back to the previous value.



Regards,

Mark


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-userD

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Patrick Storz
In reply to this post by Maren Hachmann
Am 04.12.2017 um 15:07 schrieb Maren Hachmann:
> (Screenshot attached for those who don't have a copy of the
> current development version installed)
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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user

slider_Adwaita_Win7.png (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Thorsten Wilms
In reply to this post by Tavmjong Bah
On 04.12.2017 13:53, Tavmjong Bah wrote:

> 1. It allows for a label inside the widget. This is a nice space saving
> feature. The widget handles changing the label text from black to white
> as the progress bar moves across the label.

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.


> 3. It adds the ability to drag the progress bar to change the value. If
> one drags from the top (down arrow cursor) the change follows the
> cursor directly. If one drags along the bottom half (double headed
> cursor) the change is finer and relative to the current value.

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.


> I've always found that dragging the progress bar to be a bit awkward.
> One problem is that one can not start the drag at the far right of the
> widget as that area is reserved for typing a value directly in.

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.



> Since I am rewriting this widget, I can adjust it to what people want:
>
> * Do you want the progress bar?

Yes.

> * If so, should it be the full height of the widget (quite a bit more
> complicated)?

Maybe.

> * Do you want to be able to drag the bar? With one/two methods?

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/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user

plugin_widgets_01_bright.png (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Maren Hachmann
In reply to this post by Patrick Storz
Just tested on vanilla Ubuntu 16.04. The plus/minus buttons are barely
big enough to hit them with a mouse - but the bars are actually filled
in completely...

https://inkscape.org/en/~Moini/%E2%98%85sliders

Maren

Am 04.12.2017 um 15:36 schrieb Eduard Braun:

> Am 04.12.2017 um 15:07 schrieb Maren Hachmann:
>> (Screenshot attached for those who don't have a copy of the
>> current development version installed)
> 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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Tavmjong Bah
On Mon, 2017-12-04 at 22:54 +0100, Maren Hachmann wrote:
> Just tested on vanilla Ubuntu 16.04. The plus/minus buttons are
> barely
> big enough to hit them with a mouse - but the bars are actually
> filled
> in completely...
>
> https://inkscape.org/en/~Moini/%E2%98%85sliders

Maybe it's theme dependent. What's the theme Ubuntu uses?

>
> Maren
>
> Am 04.12.2017 um 15:36 schrieb Eduard Braun:
> > Am 04.12.2017 um 15:07 schrieb Maren Hachmann:
> > > (Screenshot attached for those who don't have a copy of the
> > > current development version installed)
> >
> > 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
>
>
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget: Opinions needed!

Tavmjong Bah
On Tue, 2017-12-05 at 07:50 +0100, Tavmjong Bah wrote:

> On Mon, 2017-12-04 at 22:54 +0100, Maren Hachmann wrote:
> > Just tested on vanilla Ubuntu 16.04. The plus/minus buttons are
> > barely
> > big enough to hit them with a mouse - but the bars are actually
> > filled
> > in completely...
> >
> > https://inkscape.org/en/~Moini/%E2%98%85sliders
>
> Maybe it's theme dependent. What's the theme Ubuntu uses?
>

OK, it is definitely theme dependent. The progress bar actually does
cover the entire height of the widget (with a small margin). The
Adwaita theme makes the background transparent but sets the bottom
border width to 2px so what we are seeing is just the bottom border.

CSS:

progress {
  background: rgb(74,144,217);
}

Tav



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user