Regarding adding Names to the viewport display. I did think of this, but I wasn’t sure where these name should be displayed. Always to the left? Always centered and below the curve? It seemed really tricky to get the display location correct. The most obvious solution would be to enable a system where the name could be moved around, but that also opens up a can of worms.
Galapagos support I can look into.
Cluster support too. I’ve added a YT item (RH-91035) to track this request.
@AndersDeleuran In the screenshot you posted where you were using the RCP (in this post), the curve widget component appears to have a long black/grey vertical bar in the center of it. I’m trying to figure out what’s going on there. I can see from the other components that you have icons showing, so I’m wondering why this black bar is showing up. I’m wondering if this is a bug. Is it repeatable?
I had a look into Save State/Restore (wasn’t aware of its existence), but it isn’t what I am looking for. I would rather Save and Restore the Widget values per object by using Grasshopper script logic. I don’t want to manually fiddle with states, what I want is to iteratively modify objects as I go, read the previous value > modify > store and move on to the next object or a different task altogether with zero overhead for me.
The User Text step may seem superfluous, but I would read the User Text anyways to drive my script, it is what allows me to make looping scripts without actually creating loops in Grasshopper (read & write are distinct steps).
Also, the slider value with save states disappears on me, or I must be misunderstanding the feature completely.
I would really like to see this too. But in that case, for the curve widget, I’d like the point to report the distance away from the Domain min/max, whichever value is closest.
Hmm. That definitely looks like a bug. I’ll investigate. Thanks for reporting this. One thing that’s odd to me when watching your video is that when you click to “Save State” for state number 4, the curve and domain inputs are empty. So, when the state gets saved, the domain is likely empty or null (I’ll need to investigate this).
Yes and the idea is that when a curve is saved with the slider info in user text, it can be referenced in another file or another version of a definition and a slider widget can be fed with a saved position.
At the moment I’m using a script to set slider values. I’ll try to compose a simple example….
Indeed, it could get quite visually bloated quite fast. I was thinking that it could be part of the hover over state (edit: also exposing the hover over color would be nice). Maybe drawing it before the value, ala this:
But yeah, orientation and justification can probably become quite tricky!
I think I had it set to Always draw name and then deleted the name. Sorry for the confusion
I’d also like to join the calls for the ability to inject a widget’s initial settings. The reasons are the same. Using the Content Cache, you could return to created elements, display their current settings, and modify them via the widget. This information would need to be assigned to the object somewhere. This would also allow for a consistent display state while the same values could be modified also from the GUI window. This problem will undoubtedly arise.
Please consider a setup option to disable previewing the full domain from sliders and only display a part that is below the set value. In some cases this will work better - but by default it’s good as it is.
I hope this thing will be further developed. It’s awesome.
+1 On this. I would love to have something like this. With Grasshopper Player and Content Cache, one can have something like parametric blocks. Storing configuration data in the User Text is ok, we can read that data with the use of some GUI plugins like Synapse to pre-configure sliders but this keeps us trapped inside some Eto panel. Viewport widgets are very cool and intuitive.
Please find a way to allow user pre-configure widget sliders values in each Grasshopper Player run.
I’ve been playing with the curve slider as a means of adjusting object positions in a scene. But with a lot of objects to move individually in 3D the scene becomes cluttered with sliders.
What would be cool… …would be to have a one set of orthogonal sliders which could be associated with a specific object (perhaps by selecting that object) while that object is being manipulated, then associated to the next object while the first object remains where it has been moved to, and so on throughout a collection of objects. Any time you revert to a former object the sliders would take on that object’s last values. That way you would have the functionality without the clutter.
I don’t see the slider if I move the widget into a cluster. Can that be changed? I don’t want to have the components needed to create curves just for the sliders on the main canvas.
I would love the equivalent of all the AutoCAD dynamic block interactions: point translation on plane, mirror switch, dropdown options. Using Kangaroo for interaction can be problematic.
