Grasshopper

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.

Views: 380

Comment

You need to be a member of Grasshopper to add comments!

Comment by Daniel González Abalde on December 15, 2016 at 5:48am

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.

Comment by ng5 Alex on December 8, 2016 at 7:56am

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.

Comment by David Rutten on December 8, 2016 at 7:53am

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

Comment by David Rutten on December 8, 2016 at 7:51am

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.

Comment by ng5 Alex on December 8, 2016 at 7:39am

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

Comment by Mohamed Naeim on December 8, 2016 at 6:11am

when you say focus by mouse over it in "1", do you mean select by pressing, or by just hovering on top of it?

Comment by Mohamed Naeim on December 8, 2016 at 6:08am

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)

Comment by David Rutten on December 8, 2016 at 2:43am

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?

Comment by Mohamed Naeim on December 8, 2016 at 12:14am

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

Comment by Pieter Segeren on December 7, 2016 at 2:29pm

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

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service