Small idea or suggestion.
Boolean values in components are used very often and some components do things where mostly I use only one boolean value and almost never True & False tree structures.
After years of using Grasshopper, I found it annoying how many times I need to bring Boolean Toggle for the single boolean values. For many components, it doubles the work to set them.
I could set boolean value from right-click menu but it’s also a bit impractical.
- It’s too deep - I need to right-click, precisely hover the cursor over “Set Boolean” and choose the value.
- Once it’s made, component doesn’t show what value is set.
- In case when I choose the wrong value It takes three precise clicks on small elements to change it. - It’s tiring and slow.
Single Boolean value accessible in the second layer of the right-click menu
Slightly better is in a different case where all “Corners” opinions made it to the first layer of the menu.
Corner type directly accessible in the first layer of right-click menu
What do you think if the new standard for GH components would be that they have a little more UI in them? I don’t want to bloat them with buttons, but at least this functional small boolean toggle button could be directly accessible (also showing if it’s on or off). Not from the menu or submenu but from the component itself. If we instead connect the wire with True&False input it true/false button could get greyed out or disappear.
Right now we have the Draw Full Names option and many people use it. Maybe we can also have Show extended component’s UI option too?
Of course, GH components are highly customizable but what I mean by the standard is that plugin makers shouldn’t worry too much to keep this standard - I see it as a default functionality of boolean input.
What I like about the Grasshopper that almost every value can be provided by the wire from another component. At the same time very often it’s slow to wire everything from scratch - especially in very small definitions where I need to quickly make something and which I will not even save to a disk.
However, there are some exceptions where we can’t use wire input and I don’t like it:
I consider Dynamic Geometry Pipeline where we can wire inputs as a better component than these two others.
List Item component. I think it could benefit from a buil-in number slider with a dynamic domain (based on the List input) into it.
Similar to previous Tree Item with optional path and index sliders.
I would like to propose both buttons and wire inputs to many components at the same time - buttons could be hidden for those who don’t need them or want to have their components small and definitions visually packed (per component instance override could be handy)
Boolean Toggle is a good example:
There are too many Boolean Toggles in my definitions - I like to use them but I’ve had enough of placing and wiring them…