Separate the Goddamn Sliders from the number input please!
Dear all,
I don't know what made the new slider UI come through, but it absolutely sucks. Why in gods earth does the text input reside beneath the slider drag? Every time I want to set a blur I have to really be afraid to drag the friggin slider to 90+% and then wait and pray for Inkscape to recover from this mishap. The same for transparency. Can the sliders and the number input please be separated into their own objects rather than this highly frustrating BS object?
Especially with blur it is not immediately obvious whether you have actually clicked the right object (text input) and then click again to try and select the number input while Inkscape goes haywire calculating 90+% blurs for every friggin click you make. Don't know how this behaves on 1024x768, but this is absolutely unworkable on highres screens. The disfunctionality of this solution is not worth the few pixels gained for the slider control.
Cheers, keep up the good work ;-)
Jelle
Hi!
On Dec 21, 2014 3:21 PM, "Jelle Mulder" <jelle.mulder2@...3139...> wrote:
Dear all,
I don't know what made the new slider UI come through, but it absolutely sucks. Why in gods earth does the text input reside beneath the slider drag?
It's not beneath, it's on top of it. Although, it does depend on how you look at it, I suppose. You did notice that upper portion of it is "direct" value setting and lower part is being used to "fine tune" that value, didn't you? Widget itself is taken from GIMP, but is poorly implemented in Inkscape.
Every time I want to set a blur I have to really be afraid to drag
the friggin slider to 90+% and then wait and pray for Inkscape to recover from this mishap.
Inkscape's fault, if you ask me. Blur should be much, much faster.
The same for transparency. Can the sliders and the
number input please be separated into their own objects rather than this highly frustrating BS object?
Especially with blur it is not immediately obvious whether you have actually clicked the right object (text input) and then click again to try and select the number input while Inkscape goes haywire calculating 90+% blurs for every friggin click you make. Don't know how this behaves on 1024x768, but this is absolutely unworkable on highres screens. The disfunctionality of this solution is not worth the few pixels gained for the slider control.
It should be fixed as soon as Inkscape gets ported to newer version of toolkit it uses for GUI.
Hopefully, it's obvious that I like new slider better. ;-)
Cheers, Vladimir
Cheers, keep up the good work ;-)
Jelle
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
not a fan of multiple functionality hidden within the same widget, particularly when the functionality that you really want, which is the I-beam cursor for editing text, is incredibly difficult to find, or actuate.
see related report: https://bugs.launchpad.net/inkscape/+bug/1184408
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Separate-the-Goddamn-Sliders-from-the-numbe... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I find it far too sensitive and confusing too when I work with any filter. And with blur this is particularly annoying because of its slowness at high levels. If you miss the numeric input you are very stressed… ivan
Le Dimanche 21 décembre 2014 15h20, Jelle Mulder <jelle.mulder2@...233.....3139...> a écrit :
Dear all,
I don't know what made the new slider UI come through, but it absolutely sucks. Why in gods earth does the text input reside beneath the slider drag? Every time I want to set a blur I have to really be afraid to drag the friggin slider to 90+% and then wait and pray for Inkscape to recover from this mishap. The same for transparency. Can the sliders and the number input please be separated into their own objects rather than this highly frustrating BS object?
Especially with blur it is not immediately obvious whether you have actually clicked the right object (text input) and then click again to try and select the number input while Inkscape goes haywire calculating 90+% blurs for every friggin click you make. Don't know how this behaves on 1024x768, but this is absolutely unworkable on highres screens. The disfunctionality of this solution is not worth the few pixels gained for the slider control.
Cheers, keep up the good work ;-)
Jelle
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Let's keep discussions civil on this list. Certainly Inkscape is not free from many frustrating problems, but keep in mind the developers working on the project are all volunteers.
As to the issue at hand, do you know if there's a bug report open about this?
Bryce
On Sun, Dec 21, 2014 at 10:19:34PM +0800, Jelle Mulder wrote:
Dear all,
I don't know what made the new slider UI come through, but it absolutely sucks. Why in gods earth does the text input reside beneath the slider drag? Every time I want to set a blur I have to really be afraid to drag the friggin slider to 90+% and then wait and pray for Inkscape to recover from this mishap. The same for transparency. Can the sliders and the number input please be separated into their own objects rather than this highly frustrating BS object?
Especially with blur it is not immediately obvious whether you have actually clicked the right object (text input) and then click again to try and select the number input while Inkscape goes haywire calculating 90+% blurs for every friggin click you make. Don't know how this behaves on 1024x768, but this is absolutely unworkable on highres screens. The disfunctionality of this solution is not worth the few pixels gained for the slider control.
Cheers, keep up the good work ;-)
Jelle
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Jelle Mulder <jelle.mulder2@...360...> writes:
Dear all,
I don't know what made the new slider UI come through, but it absolutely sucks. Why in gods earth does the text input reside beneath the slider drag? Every time I want to set a blur I have to really be afraid to drag the friggin slider to 90+% and then wait and pray for Inkscape to recover from this mishap.
As a user I have to admit this is indeed a problem and it happened to me quite a lot. So, I tried to analyze the reason it fails so much. When people attempt to enter a new numerical value using text input, they first have to either place the cursor in the text, or select the old input in order to overwrite it. The most common use case is changing to a completely different value, so most of the time you'll want to start by selecting the entire value and typing you own. You do that by placing the cursor to the left of the "1" and dragging to the right, or placing it on the rightmost edge and dragging to the left - but I'm guessing most people would go left-to-right.
And herein lies the problem. turns out the cursor is still a widget manipulator if you place it just to the left of the text. In fact, it's still a manipulator even when it's on the center of the leftmost digit.
Worse: the pixels above and below the text are still manipulator territory. touch the widget a pixel above the text and you're screwed. Another design flaw that's relevant is the fact that the icon for "strong" manipulation (the one that is active on the top half of the widget) is vertical and similar in overall shape to the text entry cursor, but its hotspot (the pixel that is used as the center) is at the top, while the hotspot for the text cursor is in the middle. So, try placing the cursor a pixel or two above the text. If you don't focus and only use your peripheral vision, you'll think you are using the text cursor on the center of the text, while in fact you're not.
Solutions: 1. expand the area in which it is a text entry cursor about 6 pixels to the left and affective on the top and bottom of the text as well. 2. change the design of the "strong" manipulation so its overall shape is not a vertical line. 3. change the hotspot to the middle of the icon.
On 22 December 2014 at 06:33, Bryce Harrington <bryce@...961...> wrote:
Let's keep discussions civil on this list.
Absolutely agree.
On 22 December 2014 at 09:12, Michael Grosberg <grosberg.michael@...400...> wrote:
Jelle Mulder <jelle.mulder2@...360...> writes:
Dear all,
I don't know what made the new slider UI come through, but it absolutely sucks. Why in gods earth does the text input reside beneath the slider drag? Every time I want to set a blur I have to really be afraid to drag the friggin slider to 90+% and then wait and pray for Inkscape to recover from this mishap.
As a user I have to admit this is indeed a problem and it happened to me quite a lot. So, I tried to analyze the reason it fails so much. When people attempt to enter a new numerical value using text input, they first have to either place the cursor in the text, or select the old input in order to overwrite it. The most common use case is changing to a completely different value, so most of the time you'll want to start by selecting the entire value and typing you own. You do that by placing the cursor to the left of the "1" and dragging to the right, or placing it on the rightmost edge and dragging to the left - but I'm guessing most people would go left-to-right.
And herein lies the problem. turns out the cursor is still a widget manipulator if you place it just to the left of the text. In fact, it's still a manipulator even when it's on the center of the leftmost digit.
Worse: the pixels above and below the text are still manipulator territory. touch the widget a pixel above the text and you're screwed. Another design flaw that's relevant is the fact that the icon for "strong" manipulation (the one that is active on the top half of the widget) is vertical and similar in overall shape to the text entry cursor, but its hotspot (the pixel that is used as the center) is at the top, while the hotspot for the text cursor is in the middle. So, try placing the cursor a pixel or two above the text. If you don't focus and only use your peripheral vision, you'll think you are using the text cursor on the center of the text, while in fact you're not.
Thank you for that detailed investigation of the current UI! Obviously the UI is currently not very intuitive. Personally I didn't even realize that the upper part of the slider has a different behavior than the lower part. And it also happens quite often to me that I fail to click into the text area of the slider.
There are currently six ways to set the value:
- Clicking the upper part of the slider to set the value directly - Clicking the lower part of the slider to in-/decrease the value dragging the mouse horizontally - Typing a new value into the text field part - Pressing Up/Down while the focus is within the text field part - Clicking the Up/Down buttons at the right side of the widget - Scrolling the mouse wheel while hovering the widget
Solutions:
- expand the area in which it is a text entry cursor about 6 pixels to the left and affective on the top and bottom of the text as well.
- change the design of the "strong" manipulation so its overall shape is not a vertical line.
- change the hotspot to the middle of the icon.
I agree with Alvin that multiple functionalities within one widget is rather confusing than helping. So I believe a better solution would be to visually split both inputs again like in Inkscape 0.48.x. The slider could visually stay like it is now, though clicking the slider should only have one functionality. People may be able to switch to the other behavior by holding down Ctrl, Shift or Alt when clicking it. Allowing the mouse wheel to change the values might cause changing them by mistake in case you actually want to scroll or zoom the viewport. So IMO that behavior should be removed or just work in combination with a key.
Also I could imagine to extend the functionality of the Up/Down keys to work like in Firebug, i.e. allowing to in-/decrease by 10 holding down Shift and by 0.1 holding down Ctrl.
Sebastian
El dom, 21-12-2014 a las 21:33 -0800, Bryce Harrington escribió:
Let's keep discussions civil on this list. Certainly Inkscape is not free from many frustrating problems, but keep in mind the developers working on the project are all volunteers.
As to the issue at hand, do you know if there's a bug report open about this?
Bryce
There's an easy way to fix it: using a modifier key to enter the type-in mode. In GIMP the sliders are thicker, so there is room for the three modes (and the cursor changes indicating them), but in inkscape they have been made thinner, so it's hard to use them. What about using the CTRL key to enter the edit mode clicking anywhere on the slider? Clicking without pressing CTRL will control the slider normally, CTRL +click will switch to the numeric input mode.
Gez
Gez <listas@...360...> writes:
There's an easy way to fix it: using a modifier key to enter the type-in mode.
No need for that. if you press anywhere in the lower half of the widget, you'll select the text and be able to rewrite it. The problem is that it's not obvious to a casual user that this is happening. In fact, I only noticed it yesterday while I was investigating the widget - and I've been using Inkscape heavily for months now! In the same way, having to press a modifier key won't be obvious unless you read the manual.
On 23 December 2014 at 08:54, Michael Grosberg <grosberg.michael@...400...> wrote:
Gez <listas@...360...> writes:
There's an easy way to fix it: using a modifier key to enter the type-in mode.
... In the same way, having to press a modifier key won't be obvious unless you read the manual.
Of course a modifier key isn't very obvious, though it definitely reduces confusion. To mitigate the visibility problem the widget could have a tooltip mentioning the modifier.
In GIMP the sliders are thicker, so there is room for the three modes (and the cursor changes indicating them), but in inkscape they have been made thinner, so it's hard to use them.
The sliders thicker would also mitigate the problem a bit. Though as Michael pointed out earlier the text input field is still hard to hit. (FWIW GIMP has the same problem.)
I'm not a regular GIMP user, though I assume their slider implementation already exists longer than the one in Inkscape. So before making a change to the existing widget, I believe someone of the Inkscape team should contact the GIMP team and ask for whether they got positive or negative feedback about that widget.
Sebastian
+1 to remove the double functionality.
About blur and all other long operations that stall the program, the solution is making them stoppable (i.e. properly use multithreading), considering solving the problem making them faster is naive.
-- View this message in context: http://inkscape.13.x6.nabble.com/Separate-the-Goddamn-Sliders-from-the-numbe... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
participants (9)
-
alvinpenner
-
Bryce Harrington
-
Gez
-
Ivan Louette
-
Jelle Mulder
-
LucaDC
-
Michael Grosberg
-
Sebastian Zartner
-
Vladimir Savic