Spin slider widget, redux.

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

Spin slider widget, redux.

Tavmjong Bah

Hi all,

I've taken into account all the feedback and have developed a little
test program that shows of a number of solutions to replacing the Gimp
Spin Scale widget.

A gzipped tar file of the source code is attached so that you can try
out the solutions (should be trivial to compile on Linux if you have
the Gtk3 libraries). Not all of the solutions fully work as I didn't
take the time to make them... but you should be able to get a feel for
them. If you run in debug mode (see README) you can interactively add
CSS. I've include an example CSS file you can paste into the debug
window (ignore the colors, they were just for experimenting).

I've also attached PNGs of the widgets with and without the extra CSS.

The five solutions, from top to bottom, are:

* Custom Gtk::Range widget couple with Gtk::Spinbutton:

  This is my current favorite. It works quite well, methinks. Use the
'Alt' key to get into fine adjustment mode. It was rather simple to
implement. Could be refined further (add styling properties, rounded
corners, etc.).

* Gtk::Scrollbar coupled with Gtk::Spinbutton:

  Works rather well, but doesn't show as well the current value. Using
a narrow "slider" prevents it from covering up the text (text not
implemented yet). I didn't know it before, but if one clicks on the
slider and doesn't move for a second or two it enters into a fine-
adjustment mode.

* Gkt::ProgressBar coupled with Gtk::Spinbutton:

  CSS can get this looking pretty good but some extra work has to be
done as the ProgressBar doesn't have an "adjustment", the class that
actually handles tracking a value. The Gtk::Spinbutton actually
contains a ProgressBar but while one can style it via CSS one can't
directly access it and it overlaps the numerical entry part of the
SpinButton (this is how the Gimp widget works).

* Subclassed Gtk::Spinbutton:

  This is essentially a modified version of the Gimp widget but it has
some major flaws as one cannot access the underlying widgets
(ProgressBar, Buttons). In this example, the built in ProgressBar is
disabled and new code that simulates a narrower ProgressBar has been
added. I could not fine a good way to calculate how much narrower the
new bar needs to be to not overlap the numerical entry part. Also, when
dragging the bar it is easy to highlight the numerical text. The code
to do all this is pretty messy.

* Gtk::Scale coupled with Gtk::Spinbutton:

  CSS can make this look reasonable. Reducing the size of the circle
will prevent it from covering text (text not implemented yet).
Gtk::Scale also has a fine-adjustment mode accessed the same was as for
 a scrollbar.

Tav


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

SpinButtons_no_CSS.png (11K) Download Attachment
SpinButtons_with_CSS.png (9K) Download Attachment
spinbutton_test.tar.gz (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget, redux.

Jabier Arraiza
At the end there is a tweak for the one I like.

We also need to add a class to the widget box when activate the widget
to put in it by css a active state with box-shadow, like the one I
remove for spin buttons.

############################CSS TO DEBUG MODE########################
/*
You can type here any CSS rule recognised by GTK+.
You can temporarily disable this custom CSS by clicking on the “Pause”
button above.

Changes are applied instantly and globally, for the whole application.
*/

/*First hide less liked*/

#MySpinScale4{
opacity:0;
}
#MySpinScale3{
opacity:0;
}
#MySpinScale2{
opacity:0;
}
#MySpinScale1{
opacity:0;
}

/*add padding for better look*/
box{
 padding:10px;
}
box box{
 padding:0px;
}

/*tiny*/
spinbutton, entry, button {
  min-height: 2px;
  padding: 2px;
  margin: 0;
}

/*my winner*/

#MySpinScale5 {
background: #fff;
border:#999;
border-style:solid;
border-width:1px;
border-radius:3px;
}

#MySpinScale5 spinbutton {
   background-color: #fff;
   border-color:#eee;
   border-width:0 0 0 1px;
   border-radius:0 3px 3px 0;
   box-shadow:none; 
}
#MySpinScale5.activeNotWorkingJet {
   box-shadow: 0 0 0 1px #8080FF;
}
#############################################################

Cheers, Jabier.



On Wed, 2017-12-06 at 17:02 +0100, Tavmjong Bah wrote:

> Hi all,
>
> I've taken into account all the feedback and have developed a little
> test program that shows of a number of solutions to replacing the
> Gimp
> Spin Scale widget.
>
> A gzipped tar file of the source code is attached so that you can try
> out the solutions (should be trivial to compile on Linux if you have
> the Gtk3 libraries). Not all of the solutions fully work as I didn't
> take the time to make them... but you should be able to get a feel
> for
> them. If you run in debug mode (see README) you can interactively add
> CSS. I've include an example CSS file you can paste into the debug
> window (ignore the colors, they were just for experimenting).
>
> I've also attached PNGs of the widgets with and without the extra
> CSS.
>
> The five solutions, from top to bottom, are:
>
> * Custom Gtk::Range widget couple with Gtk::Spinbutton:
>
>   This is my current favorite. It works quite well, methinks. Use the
> 'Alt' key to get into fine adjustment mode. It was rather simple to
> implement. Could be refined further (add styling properties, rounded
> corners, etc.).
>
> * Gtk::Scrollbar coupled with Gtk::Spinbutton:
>
>   Works rather well, but doesn't show as well the current value.
> Using
> a narrow "slider" prevents it from covering up the text (text not
> implemented yet). I didn't know it before, but if one clicks on the
> slider and doesn't move for a second or two it enters into a fine-
> adjustment mode.
>
> * Gkt::ProgressBar coupled with Gtk::Spinbutton:
>
>   CSS can get this looking pretty good but some extra work has to be
> done as the ProgressBar doesn't have an "adjustment", the class that
> actually handles tracking a value. The Gtk::Spinbutton actually
> contains a ProgressBar but while one can style it via CSS one can't
> directly access it and it overlaps the numerical entry part of the
> SpinButton (this is how the Gimp widget works).
>
> * Subclassed Gtk::Spinbutton:
>
>   This is essentially a modified version of the Gimp widget but it
> has
> some major flaws as one cannot access the underlying widgets
> (ProgressBar, Buttons). In this example, the built in ProgressBar is
> disabled and new code that simulates a narrower ProgressBar has been
> added. I could not fine a good way to calculate how much narrower the
> new bar needs to be to not overlap the numerical entry part. Also,
> when
> dragging the bar it is easy to highlight the numerical text. The code
> to do all this is pretty messy.
>
> * Gtk::Scale coupled with Gtk::Spinbutton:
>
>   CSS can make this look reasonable. Reducing the size of the circle
> will prevent it from covering text (text not implemented yet).
> Gtk::Scale also has a fine-adjustment mode accessed the same was as
> for
>  a scrollbar.
>
> Tav
>
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget, redux.

Jabier Arraiza
> We also need to add a class to the widget box when activate the
> widget
> to put in it by css a active state with box-shadow, like the one I
> remove for spin buttons.

This is needed because "box" widgets don't support ":focus",
":hover"... so need a class added when active
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget, redux.

Bryce Harrington-3
In reply to this post by Tavmjong Bah
Hi Tav,

Hopefully others can chime in with more feedback, but just wanted to say
thanks for tackling it!  Looking forward to seeing it in trunk.

Bryce

On Wed, Dec 06, 2017 at 05:02:32PM +0100, Tavmjong Bah wrote:

>
> Hi all,
>
> I've taken into account all the feedback and have developed a little
> test program that shows of a number of solutions to replacing the Gimp
> Spin Scale widget.
>
> A gzipped tar file of the source code is attached so that you can try
> out the solutions (should be trivial to compile on Linux if you have
> the Gtk3 libraries). Not all of the solutions fully work as I didn't
> take the time to make them... but you should be able to get a feel for
> them. If you run in debug mode (see README) you can interactively add
> CSS. I've include an example CSS file you can paste into the debug
> window (ignore the colors, they were just for experimenting).
>
> I've also attached PNGs of the widgets with and without the extra CSS.
>
> The five solutions, from top to bottom, are:
>
> * Custom Gtk::Range widget couple with Gtk::Spinbutton:
>
>   This is my current favorite. It works quite well, methinks. Use the
> 'Alt' key to get into fine adjustment mode. It was rather simple to
> implement. Could be refined further (add styling properties, rounded
> corners, etc.).
>
> * Gtk::Scrollbar coupled with Gtk::Spinbutton:
>
>   Works rather well, but doesn't show as well the current value. Using
> a narrow "slider" prevents it from covering up the text (text not
> implemented yet). I didn't know it before, but if one clicks on the
> slider and doesn't move for a second or two it enters into a fine-
> adjustment mode.
>
> * Gkt::ProgressBar coupled with Gtk::Spinbutton:
>
>   CSS can get this looking pretty good but some extra work has to be
> done as the ProgressBar doesn't have an "adjustment", the class that
> actually handles tracking a value. The Gtk::Spinbutton actually
> contains a ProgressBar but while one can style it via CSS one can't
> directly access it and it overlaps the numerical entry part of the
> SpinButton (this is how the Gimp widget works).
>
> * Subclassed Gtk::Spinbutton:
>
>   This is essentially a modified version of the Gimp widget but it has
> some major flaws as one cannot access the underlying widgets
> (ProgressBar, Buttons). In this example, the built in ProgressBar is
> disabled and new code that simulates a narrower ProgressBar has been
> added. I could not fine a good way to calculate how much narrower the
> new bar needs to be to not overlap the numerical entry part. Also, when
> dragging the bar it is easy to highlight the numerical text. The code
> to do all this is pretty messy.
>
> * Gtk::Scale coupled with Gtk::Spinbutton:
>
>   CSS can make this look reasonable. Reducing the size of the circle
> will prevent it from covering text (text not implemented yet).
> Gtk::Scale also has a fine-adjustment mode accessed the same was as for
>  a scrollbar.
>
> Tav
>




> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel


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

Spin Slider widget: Round 3

Tavmjong Bah
In reply to this post by 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.
* Slow-mo updating glitches fixed.
* Order of drawing bar/text changed to give cleaner text.
* Improved (and more realisitic styling).
* Added a pure Gtk::SpinButton widget for reference (at bottom).
* Fixed build instructions.

Some work that still needs to be done:

* Custom styling. I've tried two approaches and can't get either to
work (and believe me, I've tried):

  * Add custom color styling to a widget (I can add an integer property
but nothing else).

  * Access the styling of the child widgets in the SpinButton,
especially the progress bar widget. I could then use those values for
styling the custom progress bar.

* A few modifications are needed to handle right-to-left layout.

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).

Tav

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

spinbutton_test2.tar.gz (8K) Download Attachment
SpinButtons2.png (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin Slider widget: Round 3

Jabier Arraiza

Hi Tavmjong.

Whats your opinion in change the container type from "Widget" to "Box"
or other container you prefear. 

https://stackoverflow.com/questions/41344241/gtkmm-c11-how-to-create-a-custom-composite-widget-out-of-other-widgets#41791719
http://ptomato.name/advanced-gtk-techniques/html/custom-container.html

Cheers, Jabier.


On Mon, 2017-12-11 at 13:35 +0100, Tavmjong Bah wrote:

> 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.
> * Slow-mo updating glitches fixed.
> * Order of drawing bar/text changed to give cleaner text.
> * Improved (and more realisitic styling).
> * Added a pure Gtk::SpinButton widget for reference (at bottom).
> * Fixed build instructions.
>
> Some work that still needs to be done:
>
> * Custom styling. I've tried two approaches and can't get either to
> work (and believe me, I've tried):
>
>   * Add custom color styling to a widget (I can add an integer
> property
> but nothing else).
>
>   * Access the styling of the child widgets in the SpinButton,
> especially the progress bar widget. I could then use those values for
> styling the custom progress bar.
>
> * A few modifications are needed to handle right-to-left layout.
>
> 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).
>
> Tav
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin Slider widget: Round 3

Patrick Storz
In reply to this post by Tavmjong Bah
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 ;-) ).

> * 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).

> * 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"?

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...

Best 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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Spin Slider widget: Round 3

Tavmjong Bah
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

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

Re: [Inkscape-user] Spin Slider widget: Round 3

C R
In reply to this post by Patrick Storz
Inkscape's speed/increment modifier convention is currently:

Alt = slower increment
Shift = faster increment
No modifier = normal (default) increment

We should definitely keep this consistent wherever it's possible to do so.

My 2p.
-C





On Tue, Dec 12, 2017 at 7:09 PM, Eduard Braun <[hidden email]> 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 ;-) ).
>
>> * 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).
>
>> * 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"?
>
> 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...
>
> Best 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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Inkscape-user] Spin Slider widget: Round 3

Patrick Storz
Am 15.12.2017 um 16:11 schrieb C R:
Inkscape's speed/increment modifier convention is currently:

Alt = slower increment
Shift = faster increment
No modifier = normal (default) increment

We should definitely keep this consistent wherever it's possible to do so.

My 2p.
-C

And where can I find a control in Inkscape that follows this "convention"?
If we have a convention I'm totally fine with sticking with it, I'm just not aware of any (and if there is none I personally prefer Ctrl over Shift over Alt).
If there is a convention it first of all needs proper documentation, so a) devs are aware of it and have a chance implementing it and b) users will have a chance of being aware of it and use it.

The only related thing I could find: While moving objects around and doing similar tasks we sometimes allow:
  • No modifier = default increment
  • Alt = move by 1 pixel instead of default increment according to keys and mouse reference
    However this does not only seem to be problematic now that we use mm as default units, it also does not seem to work as advertised: When pressing Alt the change is relative to the current zoom level instead, so it might well be larger as the default increment without modifier
  • Shift = increase amount by 10 (can be used in any combination)

Maybe you were referring to that? With the confusing behavior it's hardly a convention either, though...

If in the end we really have no convention it might be a good time to think about one!

Best 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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Spin Slider widget: Round 3

Patrick Storz
In reply to this post by Tavmjong Bah
Am 13.12.2017 um 15:13 schrieb Tavmjong Bah:
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 thought about that as well, but I realized it's not as easy as it might look initially:
  • Modifying part of the CSS quickly leads to inconsistencies in the UI. For example if we change the spinbutton in the new slider widget it will look dissimilar to normal spinbuttons, so we should probably change those, too, and with them probably other buttons/entries and sooner rather than later we end up with *a lot* of custom CSS that will be hard to maintain, especially with the second point in mind:
  • How can we ensure compatibility with system/custom themes? If we restyle our widgets we easily override CSS from other themes. For example the spinbutton CSS from the test program already broke the win32 theme I was experimenting with and I doubt other themes are more robust...

The only solution I could come up with (and it's not satisfying): Pick one theme (that's about as much as we can maintain) and force Inkscape to use it. Are there any alternatives I overlooked?


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.
What about:
* tweak toolbar
* pen toolbar
* calligraphy toolbar
* spray toolbar
* eraser toolbar
* fill toolbar

All of those use the GimpSpinScale, too, and these were the places where I think we actually *are* seriously space constrained. With Adwaita the toolbars are crowded, if not working full screen, many toolbars do not fit and widgets are hidden behind the arrow button to the right which I find extremely inconvenient to use.

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.

I fully agree that we should move forward eventually and resolving the licensing issue and designing a new widget is much appreciated.
If you think we can tailor the widget to resolve the functional concerns in hindsight that's fine by me. With my "respect" for gtk I was just afraid your work might go to waste if we ended up redesigning some aspect of the widget again...

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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Inkscape-user] Spin Slider widget: Round 3

Maren Hachmann
In reply to this post by Patrick Storz
I always felt this Alt/Shift thing was a convention - Ctrl always
*restricts* (direction, angle), Shift is for *large steps* (scale,
move), and Alt is for *small steps*.
This pattern repeats for inset, outset, moving objects, nodes, scaling
various things, see
https://inkscape.org/en/doc/keys092.html

So Alt for small steps is totally logical to me.

On Linux, to be able to use Alt+Click and many other shortcuts, you need
to deactivate Alt as a Window management key anyway (admittedly, that's
not nice, we have an extra FAQ item for it...), so I don't really see a
new issue here. Alt+Click is even more important than small steps in
some slider, and it's only available when you change your window
management settings.

Maren

Am 15.12.2017 um 20:00 schrieb Eduard Braun:

> Am 15.12.2017 um 16:11 schrieb C R:
>> Inkscape's speed/increment modifier convention is currently:
>>
>> Alt = slower increment
>> Shift = faster increment
>> No modifier = normal (default) increment
>>
>> We should definitely keep this consistent wherever it's possible to do so.
>>
>> My 2p.
>> -C
>
> And where can I find a control in Inkscape that follows this "convention"?
> If we have a convention I'm totally fine with sticking with it, I'm just
> not aware of any (and if there is none I personally prefer Ctrl over
> Shift over Alt).
> If there is a convention it first of all needs proper documentation, so
> a) devs are aware of it and have a chance implementing it and b) users
> will have a chance of being aware of it and use it.
>
> The only related thing I could find: While moving objects around and
> doing similar tasks we sometimes allow:
>
>   * No modifier = default increment
>   * Alt = move by 1 pixel instead of default increment according to keys
>     and mouse reference
>     However this does not only seem to be problematic now that we use mm
>     as default units, it also does not seem to work as advertised: When
>     pressing Alt the change is relative to the current zoom level
>     instead, so it might well be larger as the default increment without
>     modifier
>   * Shift = increase amount by 10 (can be used in any combination)
>
> Maybe you were referring to that? With the confusing behavior it's
> hardly a convention either, though...
>
> If in the end we really have no convention it might be a good time to
> think about one!
>
> Best 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-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


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

Re: [Inkscape-user] Spin Slider widget: Round 3

Patrick Storz
Am 15.12.2017 um 22:58 schrieb Maren Hachmann:
> I always felt this Alt/Shift thing was a convention - Ctrl always
> *restricts* (direction, angle), Shift is for *large steps* (scale,
> move), and Alt is for *small steps*.
> This pattern repeats for inset, outset, moving objects, nodes, scaling
> various things, see
> https://inkscape.org/en/doc/keys092.html
>
> So Alt for small steps is totally logical to me.
But that's exactly my point: It's not working like that (it's only -
wrongly? - documented like that)!
If I open Inkscape at the then default zoom level of (35%) the Alt key
causes *larger* steps.
Personally I've actually given up using modifiers to move objects as I
found it to be unpredictable and typically set numerical values manually
when I need precise positioning and can't use snapping for some reason.

All the color sliders (probably the most used ones?) do not allow any
control at all.
Numerical inputs (i.e. plain spinbuttons) do not allow any control at all.

If we make this a convention (and try to follow it) I'm fine with it,
but I hate inconsistent UI that is said to follow conventions that
people only *think* exist (because they somehow got used to the quirks)
but basically does whatever it wants in most cases leaving users who
actually try with logic out in the rain.

The "Ctrl restricts movement" is a valid argument and I would like if it
could be adapted for sliders (e.g. 10% steps in a 100% slider or 16/32
steps in 256 value slider).

> On Linux, to be able to use Alt+Click and many other shortcuts, you need
> to deactivate Alt as a Window management key anyway (admittedly, that's
> not nice, we have an extra FAQ item for it...), so I don't really see a
> new issue here. Alt+Click is even more important than small steps in
> some slider, and it's only available when you change your window
> management settings.
I'm not sure what you're saying here? As an ignorant Windows user I'm
hearing "most Linux users are not able to use the Alt key anyway, so why
bother? those who figure out how to make it usable can probably figure
out what it does, too"...
If it really is that hard to get it working - should we really rely on
it for central functionality we want to add to a new widget?

>
> Maren
>
> Am 15.12.2017 um 20:00 schrieb Eduard Braun:
>> Am 15.12.2017 um 16:11 schrieb C R:
>>> Inkscape's speed/increment modifier convention is currently:
>>>
>>> Alt = slower increment
>>> Shift = faster increment
>>> No modifier = normal (default) increment
>>>
>>> We should definitely keep this consistent wherever it's possible to do so.
>>>
>>> My 2p.
>>> -C
>> And where can I find a control in Inkscape that follows this "convention"?
>> If we have a convention I'm totally fine with sticking with it, I'm just
>> not aware of any (and if there is none I personally prefer Ctrl over
>> Shift over Alt).
>> If there is a convention it first of all needs proper documentation, so
>> a) devs are aware of it and have a chance implementing it and b) users
>> will have a chance of being aware of it and use it.
>>
>> The only related thing I could find: While moving objects around and
>> doing similar tasks we sometimes allow:
>>
>>    * No modifier = default increment
>>    * Alt = move by 1 pixel instead of default increment according to keys
>>      and mouse reference
>>      However this does not only seem to be problematic now that we use mm
>>      as default units, it also does not seem to work as advertised: When
>>      pressing Alt the change is relative to the current zoom level
>>      instead, so it might well be larger as the default increment without
>>      modifier
>>    * Shift = increase amount by 10 (can be used in any combination)
>>
>> Maybe you were referring to that? With the confusing behavior it's
>> hardly a convention either, though...
>>
>> If in the end we really have no convention it might be a good time to
>> think about one!
>>
>> Best 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-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel


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

Re: [Inkscape-user] Spin Slider widget: Round 3

Maren Hachmann
Am 15.12.2017 um 23:36 schrieb Eduard Braun:

> Am 15.12.2017 um 22:58 schrieb Maren Hachmann:
>> I always felt this Alt/Shift thing was a convention - Ctrl always
>> *restricts* (direction, angle), Shift is for *large steps* (scale,
>> move), and Alt is for *small steps*.
>> This pattern repeats for inset, outset, moving objects, nodes, scaling
>> various things, see
>> https://inkscape.org/en/doc/keys092.html
>>
>> So Alt for small steps is totally logical to me.
> But that's exactly my point: It's not working like that (it's only -
> wrongly? - documented like that)!
> If I open Inkscape at the then default zoom level of (35%) the Alt key
> causes *larger* steps.

- It doesn't for me ... ? Opened Inkscape with new document, drew
rectangle, switched to select tool, used Alt+Arrow > small steps, used
Shift+Arrow > big steps. Maybe we have discovered a new Windows-only
bug? Or which functionality/shortcut did you try?

> Personally I've actually given up using modifiers to move objects as I
> found it to be unpredictable and typically set numerical values manually
> when I need precise positioning and can't use snapping for some reason.

- I use Alt+arrows as well as Shift+arrows happily. But of course, for
me they work ;-)

> All the color sliders (probably the most used ones?) do not allow any
> control at all.
> Numerical inputs (i.e. plain spinbuttons) do not allow any control at all.
>
> If we make this a convention (and try to follow it) I'm fine with it,
> but I hate inconsistent UI that is said to follow conventions that
> people only *think* exist (because they somehow got used to the quirks)
> but basically does whatever it wants in most cases leaving users who
> actually try with logic out in the rain.

- I understand (and feel similarly, consistency is great :) )

> The "Ctrl restricts movement" is a valid argument and I would like if it
> could be adapted for sliders (e.g. 10% steps in a 100% slider or 16/32
> steps in 256 value slider).
>
>> On Linux, to be able to use Alt+Click and many other shortcuts, you need
>> to deactivate Alt as a Window management key anyway (admittedly, that's
>> not nice, we have an extra FAQ item for it...), so I don't really see a
>> new issue here. Alt+Click is even more important than small steps in
>> some slider, and it's only available when you change your window
>> management settings.
> I'm not sure what you're saying here? As an ignorant Windows user I'm
> hearing "most Linux users are not able to use the Alt key anyway, so why
> bother? those who figure out how to make it usable can probably figure
> out what it does, too"...
> If it really is that hard to get it working - should we really rely on
> it for central functionality we want to add to a new widget?

- It's that I don't consider the slider extra tricks as important as
Alt+Click for normal use (there's no simple replacement for Alt+Click,
but there's a number entry for the slider) - so, I mean, we are already
making it hard for users to access important functionality, what's this
in comparison?

It is already problematic now (it's not Linux directly, but some window
management systems that use Alt+Click for moving windows, maybe Alt+Drag
also doesn't work by default, but not sure), and those who need advanced
functionality will have that setting changed already. It seems to be an
issue with other graphics applications as well (e.g. Blender and Maya
seem to be affected by this choice, too).

Those who haven't changed the setting (or don't know about it) will miss
out on both functions (or even more), yes. Usually, people notice when
they want to select an object that is below another one, after reading
documentation. And yes, that's sad... But it's hard to change that
shortcut after the fact...

I personally find the consistency more important here - but I understand
if you don't agree.

Maren

>> Maren
>>
>> Am 15.12.2017 um 20:00 schrieb Eduard Braun:
>>> Am 15.12.2017 um 16:11 schrieb C R:
>>>> Inkscape's speed/increment modifier convention is currently:
>>>>
>>>> Alt = slower increment
>>>> Shift = faster increment
>>>> No modifier = normal (default) increment
>>>>
>>>> We should definitely keep this consistent wherever it's possible to
>>>> do so.
>>>>
>>>> My 2p.
>>>> -C
>>> And where can I find a control in Inkscape that follows this
>>> "convention"?
>>> If we have a convention I'm totally fine with sticking with it, I'm just
>>> not aware of any (and if there is none I personally prefer Ctrl over
>>> Shift over Alt).
>>> If there is a convention it first of all needs proper documentation, so
>>> a) devs are aware of it and have a chance implementing it and b) users
>>> will have a chance of being aware of it and use it.
>>>
>>> The only related thing I could find: While moving objects around and
>>> doing similar tasks we sometimes allow:
>>>
>>>    * No modifier = default increment
>>>    * Alt = move by 1 pixel instead of default increment according to
>>> keys
>>>      and mouse reference
>>>      However this does not only seem to be problematic now that we
>>> use mm
>>>      as default units, it also does not seem to work as advertised: When
>>>      pressing Alt the change is relative to the current zoom level
>>>      instead, so it might well be larger as the default increment
>>> without
>>>      modifier
>>>    * Shift = increase amount by 10 (can be used in any combination)
>>>
>>> Maybe you were referring to that? With the confusing behavior it's
>>> hardly a convention either, though...
>>>
>>> If in the end we really have no convention it might be a good time to
>>> think about one!
>>>
>>> Best 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-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>>
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Inkscape-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>


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

Re: [Inkscape-user] Spin Slider widget: Round 3

Patrick Storz
Am 16.12.2017 um 01:24 schrieb Maren Hachmann:

> Am 15.12.2017 um 23:36 schrieb Eduard Braun:
>> Am 15.12.2017 um 22:58 schrieb Maren Hachmann:
>>> I always felt this Alt/Shift thing was a convention - Ctrl always
>>> *restricts* (direction, angle), Shift is for *large steps* (scale,
>>> move), and Alt is for *small steps*.
>>> This pattern repeats for inset, outset, moving objects, nodes, scaling
>>> various things, see
>>> https://inkscape.org/en/doc/keys092.html
>>>
>>> So Alt for small steps is totally logical to me.
>> But that's exactly my point: It's not working like that (it's only -
>> wrongly? - documented like that)!
>> If I open Inkscape at the then default zoom level of (35%) the Alt key
>> causes *larger* steps.
> - It doesn't for me ... ? Opened Inkscape with new document, drew
> rectangle, switched to select tool, used Alt+Arrow > small steps, used
> Shift+Arrow > big steps. Maybe we have discovered a new Windows-only
> bug? Or which functionality/shortcut did you try?
I compared Arrow (without modifier) and Alt + Arrow. The modifier-less
variant resulted in smaller steps (0.529 mm) than the variant with Alt
(0.756 mm).
Holding Shift additionally will multiply by ten in both cases (i.e.
7.559 mm and  5.292 mm respectively).

The problem (or at least the behavior that always confused me) is that
the variant with alt changes with the zoom level (i.e. at 70% zoom
instead of 35% zoom I get 0.378 mm steps which is exactly half the step
size from above). I'd have to look into the code to understand what is
going on here, but Alt + Arrow certainly does not seem to move "by one
px". If I had to guess it might mean "1 px on the monitor" but that
seems like a pretty arbitrary value that will not likely relate to any
lengths in the document...).

>
>> Personally I've actually given up using modifiers to move objects as I
>> found it to be unpredictable and typically set numerical values manually
>> when I need precise positioning and can't use snapping for some reason.
> - I use Alt+arrows as well as Shift+arrows happily. But of course, for
> me they work ;-)
>
>> All the color sliders (probably the most used ones?) do not allow any
>> control at all.
>> Numerical inputs (i.e. plain spinbuttons) do not allow any control at all.
>>
>> If we make this a convention (and try to follow it) I'm fine with it,
>> but I hate inconsistent UI that is said to follow conventions that
>> people only *think* exist (because they somehow got used to the quirks)
>> but basically does whatever it wants in most cases leaving users who
>> actually try with logic out in the rain.
> - I understand (and feel similarly, consistency is great :) )
>
>> The "Ctrl restricts movement" is a valid argument and I would like if it
>> could be adapted for sliders (e.g. 10% steps in a 100% slider or 16/32
>> steps in 256 value slider).
>>
>>> On Linux, to be able to use Alt+Click and many other shortcuts, you need
>>> to deactivate Alt as a Window management key anyway (admittedly, that's
>>> not nice, we have an extra FAQ item for it...), so I don't really see a
>>> new issue here. Alt+Click is even more important than small steps in
>>> some slider, and it's only available when you change your window
>>> management settings.
>> I'm not sure what you're saying here? As an ignorant Windows user I'm
>> hearing "most Linux users are not able to use the Alt key anyway, so why
>> bother? those who figure out how to make it usable can probably figure
>> out what it does, too"...
>> If it really is that hard to get it working - should we really rely on
>> it for central functionality we want to add to a new widget?
> - It's that I don't consider the slider extra tricks as important as
> Alt+Click for normal use (there's no simple replacement for Alt+Click,
> but there's a number entry for the slider) - so, I mean, we are already
> making it hard for users to access important functionality, what's this
> in comparison?
>
> It is already problematic now (it's not Linux directly, but some window
> management systems that use Alt+Click for moving windows, maybe Alt+Drag
> also doesn't work by default, but not sure), and those who need advanced
> functionality will have that setting changed already. It seems to be an
> issue with other graphics applications as well (e.g. Blender and Maya
> seem to be affected by this choice, too).
>
> Those who haven't changed the setting (or don't know about it) will miss
> out on both functions (or even more), yes. Usually, people notice when
> they want to select an object that is below another one, after reading
> documentation. And yes, that's sad... But it's hard to change that
> shortcut after the fact...
>
> I personally find the consistency more important here - but I understand
> if you don't agree.
>
> Maren
>
>>> Maren
>>>
>>> Am 15.12.2017 um 20:00 schrieb Eduard Braun:
>>>> Am 15.12.2017 um 16:11 schrieb C R:
>>>>> Inkscape's speed/increment modifier convention is currently:
>>>>>
>>>>> Alt = slower increment
>>>>> Shift = faster increment
>>>>> No modifier = normal (default) increment
>>>>>
>>>>> We should definitely keep this consistent wherever it's possible to
>>>>> do so.
>>>>>
>>>>> My 2p.
>>>>> -C
>>>> And where can I find a control in Inkscape that follows this
>>>> "convention"?
>>>> If we have a convention I'm totally fine with sticking with it, I'm just
>>>> not aware of any (and if there is none I personally prefer Ctrl over
>>>> Shift over Alt).
>>>> If there is a convention it first of all needs proper documentation, so
>>>> a) devs are aware of it and have a chance implementing it and b) users
>>>> will have a chance of being aware of it and use it.
>>>>
>>>> The only related thing I could find: While moving objects around and
>>>> doing similar tasks we sometimes allow:
>>>>
>>>>     * No modifier = default increment
>>>>     * Alt = move by 1 pixel instead of default increment according to
>>>> keys
>>>>       and mouse reference
>>>>       However this does not only seem to be problematic now that we
>>>> use mm
>>>>       as default units, it also does not seem to work as advertised: When
>>>>       pressing Alt the change is relative to the current zoom level
>>>>       instead, so it might well be larger as the default increment
>>>> without
>>>>       modifier
>>>>     * Shift = increase amount by 10 (can be used in any combination)
>>>>
>>>> Maybe you were referring to that? With the confusing behavior it's
>>>> hardly a convention either, though...
>>>>
>>>> If in the end we really have no convention it might be a good time to
>>>> think about one!
>>>>
>>>> Best 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-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Inkscape-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>


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

Re: [Inkscape-user] Spin Slider widget: Round 3

Maren Hachmann
Am 16.12.2017 um 01:47 schrieb Eduard Braun:
> I compared Arrow (without modifier) and Alt + Arrow. The modifier-less
> variant resulted in smaller steps (0.529 mm) than the variant with Alt
> (0.756 mm).
> Holding Shift additionally will multiply by ten in both cases (i.e.
> 7.559 mm and  5.292 mm respectively).

- Ah. Yes, Alt / Shift modified movements are screen pixels, and get
finer when you zoom in, and rougher when you zoom out, while arrow
movements move by a set amount of document pixels (that you can change
in the settings). That's true (but doesn't change the relationship
between Alt + Shift).
And it also appears inconsistent - but inconsistent to make things more
convenient... if that makes any sense.

It is documented correctly:
https://inkscape.org/en/doc/keys092.html#d0e2698

Maren

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

Re: [Inkscape-user] Spin Slider widget: Round 3

Patrick Storz


Am 16.12.2017 um 01:59 schrieb Maren Hachmann:

> Am 16.12.2017 um 01:47 schrieb Eduard Braun:
>> I compared Arrow (without modifier) and Alt + Arrow. The modifier-less
>> variant resulted in smaller steps (0.529 mm) than the variant with Alt
>> (0.756 mm).
>> Holding Shift additionally will multiply by ten in both cases (i.e.
>> 7.559 mm and  5.292 mm respectively).
> - Ah. Yes, Alt / Shift modified movements are screen pixels, and get
> finer when you zoom in, and rougher when you zoom out, while arrow
> movements move by a set amount of document pixels (that you can change
> in the settings). That's true (but doesn't change the relationship
> between Alt + Shift).
> And it also appears inconsistent - but inconsistent to make things more
> convenient... if that makes any sense.
Not really, sorry... It's one of the "quirks" which makes Inkscape
unnecessarily hard to use for the uninitiated.
While I'm a proponent of pixels as document units I really don't think
screen pixels are ever a useful measure for manipulating objects in the
document.

I can understand the potential need for absolute movements and relative
movements depending on zoom level but in both cases it should be
proportional to document units. In the latter case the relative amount
should be something like 1/zoom_level * document_units (e.g. at 100%
zoom level Alt+arrow would move by 1 mm if document units are set to mm
and at 1000% zoom level Alt+arrow would move by 0.1 mm. If document
units are changed to px at 100% zoom level Alt+Arrow would move by 1 px,
etc.).

Does anybody think this would be a bad idea (I almost don't dare to ask,
but the current behavior gives me the shivers...)?

> It is documented correctly:
> https://inkscape.org/en/doc/keys092.html#d0e2698
It does not mention anywhere pixels in the Alt-case are actual screen
pixels (it only mentions they are *not* screen pixels in the case
without modifiers - which I believe makes most people assume the same
for the Alt-case where it's plain wrong)... At some point I realized
that this must be the reason for the "inexplicable" behavior but without
guessing it remains a mystery in my opinion.

> Maren


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

Re: [Inkscape-user] Spin Slider widget: Round 3

Maren Hachmann
Am 16.12.2017 um 03:09 schrieb Eduard Braun:

>
>
> Am 16.12.2017 um 01:59 schrieb Maren Hachmann:
>> Am 16.12.2017 um 01:47 schrieb Eduard Braun:
>>> I compared Arrow (without modifier) and Alt + Arrow. The modifier-less
>>> variant resulted in smaller steps (0.529 mm) than the variant with Alt
>>> (0.756 mm).
>>> Holding Shift additionally will multiply by ten in both cases (i.e.
>>> 7.559 mm and  5.292 mm respectively).
>> - Ah. Yes, Alt / Shift modified movements are screen pixels, and get
>> finer when you zoom in, and rougher when you zoom out, while arrow
>> movements move by a set amount of document pixels (that you can change
>> in the settings). That's true (but doesn't change the relationship
>> between Alt + Shift).
>> And it also appears inconsistent - but inconsistent to make things more
>> convenient... if that makes any sense.
> Not really, sorry... It's one of the "quirks" which makes Inkscape
> unnecessarily hard to use for the uninitiated.
> While I'm a proponent of pixels as document units I really don't think
> screen pixels are ever a useful measure for manipulating objects in the
> document.
>
> I can understand the potential need for absolute movements and relative
> movements depending on zoom level but in both cases it should be
> proportional to document units. In the latter case the relative amount
> should be something like 1/zoom_level * document_units (e.g. at 100%
> zoom level Alt+arrow would move by 1 mm if document units are set to mm
> and at 1000% zoom level Alt+arrow would move by 0.1 mm. If document
> units are changed to px at 100% zoom level Alt+Arrow would move by 1 px,
> etc.).
>
> Does anybody think this would be a bad idea (I almost don't dare to ask,
> but the current behavior gives me the shivers...)?

- Me... I like the current behaviour, because it allows me to move by
the smallest visible distance, and that's often what I want (but I like
how your suggestion is consistent). But probably that question should be
asked in a different thread on the user mailing list, because you could
get some more representative feedback from the user base.

>> It is documented correctly:
>> https://inkscape.org/en/doc/keys092.html#d0e2698
> It does not mention anywhere pixels in the Alt-case are actual screen
> pixels (it only mentions they are *not* screen pixels in the case
> without modifiers - which I believe makes most people assume the same
> for the Alt-case where it's plain wrong)... At some point I realized
> that this must be the reason for the "inexplicable" behavior but without
> guessing it remains a mystery in my opinion.

- Mhm, now that you say it, I can see how it can be confusing. I've just
inferred the intended meaning, when I encountered it while translating
the document. But we can make that better now, whatever way it will be
:) (thanks to all the work you invested into the docs repo).

Maren

>> Maren
>
>


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