algorithmic modeling for Rhino
Slider objects are just about finished. Only thing lacking is the textfield input. This animation shows (in order of appearance):
(0:00) Three types of slider display; knob, bar and grip. The bar slider has an icon associated with it instead of text. The sliders have been added to the same 'bundle', meaning they co-ordinate their layout so that the rail and the grips line up vertically.
(0:06) Numeric popup while dragging a knob.
(0:20) One of the states of the icon can be slaved to the slider value, thus resulting in an animated icon.
(0:30) A slider with named presets and snapping. Presets need not be spaced equally.
(0:40) Slider values can be incremented/decremented by the smallest possible amount using the [-] or [+] keys, or the arrow keys.
(0:53) Sliders can be snapped to the nearest preset using [.]
(1:01) Sliders can be set to the lowest/highest possible value using [Home] or [End]
(1:12) Zooming in increases the accuracy of a slider.
Tags:
Comment
Hi David, some suggestions:
1) An interval slider. It has a domain/bounds (like the normal numeric slider) in which you can move a start-of-interval grip/knob and another end-of-interval grip/knob. Currently we need three components to do it in the usual way (2 slider and a construc domain). This would clearly be an improvement.
2) All the numerical sliders could extend their domain/bounds when the grip is tried to take beyond its limits while a key is pressed.
3) Why not add in a single slider several grips/knobs to return a list of values? This could be complemented with different ways of manipulating it (one at a time, all at the same time, maintaining proportions...) and with different attributes (color, grip type, etc).
By the way, it has not been clear to me if the sliders will continue to visualize their value all the time. Hope so.
Thanks for the consideration.
when mouse pointer meets the upper bound of the screen, increasing stops, while in max mouse pointer jumps to bottom of screen to continue increasing values
tbh i am not a fan of this feature, but i guess many users might want this.
(when mouse pointer meets the upper bound of the screen, increasing stops, while in max mouse pointer jumps to bottom of screen to continue increasing values).
That is something I hope to do better. At present Eto doesn't allow one to set the mouse position, but I've asked Curtis to add such a feature. Then the mouse can be wrapped inside some virtual box.
when you say focus by mouse over it in "1", do you mean select by pressing, or by just hovering on top of it?
I mean one of the mouse buttons has to go down over a slider. In a context where there is no zooming/scrolling the Wheel event can instead be deferred to whatever object is underneath the mouse. But that will then result in inconsistent UI behaviour.
i think what you are describing in 3ds max, can be found in gh in digit scroller, but there is no bounds values and the screen boundary is not in wrap mode (when mouse pointer meets the upper bound of the screen, increasing stops, while in max mouse pointer jumps to bottom of screen to continue increasing values).
when you say focus by mouse over it in "1", do you mean select by pressing, or by just hovering on top of it?
in 3ds max modifier parameters, there is small number boxes with two arrows beside it
when the mouse over the arrows and you simply drag up and down along the window while pressing, without releasing: the value change dramatically (fast to the bounds)
1) No. that would interfere with zooming, the slider needs to at least have focus before it starts responding to events, and the only way at the moment to get focus is to mouse-down over it.
2) I don't know how 3D Studio Max works with sliders. Is there a detailed explanation/video somewhere I can learn about this?
Hi David,
Is it possible to have one of these two possibilities in the sliders ( just suggestions)
1- when the mouse cursor on top of the slider region: to be able to change value of slider by mouse scrolling
2- when the mouse on top of the slider region && PRESSED : be able to move up and down all the way up and down the screen to change values, the way we do in 3Ds max
Ah, now I see what you meant and showed. Thanks for the explanations David, sorry I was a bit cross-eyed there.
But then again, I got to express my main [Number Slider] component/host wish: only move it on the canvas when grabbing the label (like the current Toggle and Button for instance).
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!