Some controls (such as the Width in Calligraphic/Tweak/Eraser tools, Tremor, Wiggle, and Mass in Calligraphic, Threshold in Paintbucket, Tolerance in Pencil) are converted from numeric editable fields into draggable sliders. As these values don't usually require much precision, this makes adjusting them much easier and faster.
bulia byak wrote:
Some controls (such as the Width in Calligraphic/Tweak/Eraser tools, Tremor, Wiggle, and Mass in Calligraphic, Threshold in Paintbucket, Tolerance in Pencil) are converted from numeric editable fields into draggable sliders. As these values don't usually require much precision, this makes adjusting them much easier and faster.
Can numbers still be manually set numerically though?
-Josh
On Mon, Jun 30, 2008 at 7:58 PM, Josh Andler <scislac@...400...> wrote:
Can numbers still be manually set numerically though?
You can right-click for a menu of values. Other than that, why would you need to set Width numerically? It's not an absolute number anyway, just a relative "more/less" type of control.
bulia byak wrote:
On Mon, Jun 30, 2008 at 7:58 PM, Josh Andler <scislac@...400...> wrote:
Can numbers still be manually set numerically though?
You can right-click for a menu of values. Other than that, why would you need to set Width numerically? It's not an absolute number anyway, just a relative "more/less" type of control.
It's probably the illusion/feeling of control. It's similar to the "stitch subpath" lpe... I rarely crack open the XML editor to edit a "random" seed number, but I have used it and wouldn't want to rely on "unreproducible" randomness again. Weird comparison to say the least, but it puts my OCD at ease because I *can* control it (regardless of how minutely). ;)
Either way, that was the why... I'm sure the right-click will be sufficient enough.
-Josh
On Mon, Jun 30, 2008 at 8:42 PM, Josh Andler <scislac@...400...> wrote:
Either way, that was the why... I'm sure the right-click will be sufficient enough.
Perhaps for you the best solution would be to add some presets.
On Jun 30, 2008, at 3:58 PM, Josh Andler wrote:
bulia byak wrote:
Some controls (such as the Width in Calligraphic/Tweak/Eraser tools, Tremor, Wiggle, and Mass in Calligraphic, Threshold in Paintbucket, Tolerance in Pencil) are converted from numeric editable fields into draggable sliders. As these values don't usually require much precision, this makes adjusting them much easier and faster.
Can numbers still be manually set numerically though?
The change to slider is via a hint string added in the internal toolbar XML. So you can tweak that for your local compiles.
I'm trying to get the generic unified XML format figured out. Once that's figured then we can have the toolbar definitions loaded from XML at startup, and allow for easy user configuration.
BTW... I'm looking at kicking in scale buttons instead of the hscale.
On Tue, Jul 1, 2008 at 2:55 AM, bulia byak wrote:
Some controls (such as the Width in Calligraphic/Tweak/Eraser tools, Tremor, Wiggle, and Mass in Calligraphic, Threshold in Paintbucket, Tolerance in Pencil) are converted from numeric editable fields into draggable sliders. As these values don't usually require much precision, this makes adjusting them much easier and faster.
This is infinitely cool :), but do we want some sort of common UI decision between Inkscape and GIMP here?
Here is how GtkScaleButton looks for GIMP/trunk (any brush-based tool): 1.png, 2.png
Alexandre
On Tue, Jul 1, 2008 at 10:43 AM, Alexandre Prokoudine
Here is how GtkScaleButton looks for GIMP/trunk (any brush-based tool): 1.png, 2.png
That would be nice to have, yes.
Interestingly, apparently Gimp folks consider their interface so good that they can spend time on creating fancy widgets :) Our little app, unfortunately, is still quite lame in a lot of places, and all we're doing is just patching holes - so I just grabbed the standard widget from GTK.
On Jul 1, 2008, at 7:50 AM, bulia byak wrote:
On Tue, Jul 1, 2008 at 10:43 AM, Alexandre Prokoudine
Here is how GtkScaleButton looks for GIMP/trunk (any brush-based tool): 1.png, 2.png
That would be nice to have, yes.
Interestingly, apparently Gimp folks consider their interface so good that they can spend time on creating fancy widgets :) Our little app, unfortunately, is still quite lame in a lot of places, and all we're doing is just patching holes - so I just grabbed the standard widget from GTK.
Actually my change from last night switches to using that GtkScaleButton.
It takes a list of stock icon names for what to display. In the GIMP there they have some custom icons with increasing bars. I started things with just temporary use of existing stock icons. However I am going through the docs to figure out how to get Inkscape rendered icons to show up through the icon factory interface and thus allow us to have custom icons.
FYI the internal list has the icon for the zero state, the icon for the max state, then a series that divide up the range when you're not at 0 nor 100.
On Tue, Jul 1, 2008 at 12:38 PM, Jon A. Cruz <jon@...18...> wrote:
It takes a list of stock icon names for what to display. In the GIMP there they have some custom icons with increasing bars.
So can we just borrow gimp's icons? I don't care if they're not SVG for now, they convey the message very well.
One thing I'm personally missing, however, is a number that the standard hscale displays above the slider. Can we readd it? It is useful for small adjustments (not that I care about the absolute value, but watching the number is a good way to make sure I'm e.g. slightly lowering it) and for documentation ("set width to 10" is much clearer than "drag the slider so it's approximately 10% from bottom"). Actually, now that I think of it, these disadvantages appear pretty serious to me, and if they are not fixed I think I would vote for the standard hslider, even though it takes more room and is not as sexy.
It's another type of custom ctrl I guess, but Blender uses ctrls that look something like this
< 45.3 >
Clicking on the arrow heads changes the value by a set amount.
Clicking on the control but not on the arrowhead or number and then dragging the mouse across the screen changes the number proportional to the mouse movement, as if you'd grabbed a large imaginary invisible slider/scrollbar type control.
Clicking on the number itself goes into text entry mode, with the number selected so the first character typed replaces it.
So, manual entry precision, quick large adjustments, and one click small adjustments in one compact widget.
Adobe Premiere (video editing) uses something similar, maybe other Adobe products also, I don't use them.
Cheers -Terry
On Tue, Jul 1, 2008 at 3:37 PM, Terry Brown <terry_n_brown@...36...> wrote:
It's another type of custom ctrl I guess, but Blender uses ctrls that look something like this
< 45.3 >
Clicking on the arrow heads changes the value by a set amount.
This is what we always had. All numeric spinbuttons have those arrow buttons. The idea is to make it possible to use dragging, not clicking, which is much faster and easier (though less precise).
Clicking on the control but not on the arrowhead or number and then dragging the mouse across the screen changes the number proportional to the mouse movement, as if you'd grabbed a large imaginary invisible slider/scrollbar type control.
And this is what we don't have, and what has been proposed more that once. But I think it's a change GTK should make in their spinbutton control, then we get it for free.
Still, for some values a hslider is even better than this, as it gives a clear visual clue as to where in the allowed range your value is. Its only disadvantage is you cannot type a value, but I think we can live with that for things like Width or Force.
"bulia byak" <buliabyak@...400...> writes:
On Tue, Jul 1, 2008 at 3:37 PM, Terry Brown <terry_n_brown@...36...> wrote:
It's another type of custom ctrl I guess, but Blender uses ctrls that look something like this
< 45.3 >
Clicking on the arrow heads changes the value by a set amount.
This is what we always had. All numeric spinbuttons have those arrow buttons. The idea is to make it possible to use dragging, not clicking, which is much faster and easier (though less precise).
Clicking on the control but not on the arrowhead or number and then dragging the mouse across the screen changes the number proportional to the mouse movement, as if you'd grabbed a large imaginary invisible slider/scrollbar type control.
And this is what we don't have, and what has been proposed more that once. But I think it's a change GTK should make in their spinbutton control, then we get it for free.
Still, for some values a hslider is even better than this, as it gives a clear visual clue as to where in the allowed range your value is. Its only disadvantage is you cannot type a value, but I think we can live with that for things like Width or Force.
I think losing the ability to enter a value numerically is a big problem for usability, since it reduces reproducibility (if you move the slider away from your favorite value, can you find it again?), and as you said it is useful for documentation.
As for the blender ctrl, i guess the position of the number within the control reflects the position of the value within the allowed interval, which alleviates your criticism.
Example: <-----------90-> versus <-10----------->
Dragging is still possible, but it is a tad unintuitive as you have to click out of the slider (on the dashes on my example) to start drawing. Maybe this could be remedied by having a drag surface around the numeric value where one can grab the slider to drag (pipes on my example).
<-----------|||90|||-> versus <-|||10|||----------->
Florent
On Tue, Jul 1, 2008 at 4:32 PM, Florent Becker <florent.becker@...1880...> wrote:
I think losing the ability to enter a value numerically is a big problem for usability
Not always. It depends on the nature of the value.
since it reduces reproducibility (if you move the slider away from your favorite value, can you find it again?),
For those values that we use it for - width, force, etc - perfect reproducibility is _already_ impossible, because you cannot draw two strokes with exactly the same path and pressure. So we're not losing anything.
and as you said it is useful for documentation.
If we have the hscales with the numeric value, then it's good enough for documentation imho. You can read your value and set a value you're given with enough precision for practical purposes.
As for the blender ctrl, i guess the position of the number within the control reflects the position of the value within the allowed interval, which alleviates your criticism.
Example: <-----------90-> versus <-10----------->
Not from the description I read. I don't have Blender right now so I can't check, is this so?
On Tue, 1 Jul 2008 16:47:00 -0300 "bulia byak" <buliabyak@...400...> wrote:
Example: <-----------90-> versus <-10----------->
Not from the description I read. I don't have Blender right now so I can't check, is this so?
No, Blender doesn't do that, but it's not a bad idea, if someone was building such a ctrl.
Blender's at http://www.blender.org/ for those that don't know it. It's a 3D editing / animating / ray-tracing type tool, very fun but like most of those things the learning curve's rough at the beginning. The interface is implemented in OpenGL, so it's widgets are zoomable, I guess you can do that with SVG too.
Cheers -Terry
On Tue, Jul 1, 2008 at 10:43 PM, bulia byak wrote:
Clicking on the control but not on the arrowhead or number and then dragging the mouse across the screen changes the number proportional to the mouse movement, as if you'd grabbed a large imaginary invisible slider/scrollbar type control.
And this is what we don't have, and what has been proposed more that once. But I think it's a change GTK should make in their spinbutton control, then we get it for free.
Still, for some values a hslider is even better than this, as it gives a clear visual clue as to where in the allowed range your value is. Its only disadvantage is you cannot type a value, but I think we can live with that for things like Width or Force.
I think it's time to introduce you to Phat widgets :)
Alexandre
Alexandre Prokoudine wrote:
I think it's time to introduce you to Phat widgets :)
What are some opinions about the cost/value of using internally maintained custom widgets, externally maintained custom widgets and standard GTK widgets?
Aaron Spike
And another big problem with these "volume controls": they don't keep the old value. If the last time the knob was pulled down to 0, next time I click on the icon, the slider appears and the knob at once jumps to where my mouse is, far from 0. So, essentially, I cannot adjust my value a little, I have to set it anew from scratch every time. Unless this can be fixed somehow, I think it's a very serious usability problem that justifies a return to plain hscales.
And now I moved the labels to be on top of the slider, next to the value. Much more compact this way, now the Calligraphic bar is again visible on my screen in its entirety.
On Mon, Jun 30, 2008 at 7:55 PM, bulia byak <buliabyak@...400...> wrote:
Some controls (such as the Width in Calligraphic/Tweak/Eraser tools, Tremor, Wiggle, and Mass in Calligraphic, Threshold in Paintbucket, Tolerance in Pencil) are converted from numeric editable fields into draggable sliders. As these values don't usually require much precision, this makes adjusting them much easier and faster.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (7)
-
Aaron Spike -
Alexandre Prokoudine -
bulia byak -
Florent Becker -
Jon A. Cruz -
Josh Andler -
Terry Brown