-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improving optional/settings parameter provision #20
Comments
Some loose thoughts on UI. We'd set everything to be optional and provide reasonable defaults to just plug & play. It would be nice to allow users to add/remove these via the VariableParameterComponent Interface. I.e. if someone only cares about slope analysis, they can remove all the other options by clicking on the minus sign to reduce visual clutter. Something to think about while setting up #23 |
The sketch of the different setting types makes sense. One thing to note is that I'm pretty sure its possible to dynamically add/remove input parameters to a definition via its internal logic. So it could work that the 'main' component starts of with a very minimal set of 'core' options (e.g. sensor height and columns) along with inputs for the specialised settings components. Then, if an analysis mode is selected that requires basic customisation, any necessary input parameters could be revealed (e.g. water level or contour interval). Alternately, if one of the specialised settings components is wired up, any redundant input options could be removed from the core component itself. That might sound a little unintuitive, but could be worth trying out as a possible best-of-both-worlds. |
I was thinking about automatic adding/removal of input parameters. How would you solve the case of switching between analysis methods? Then we switch to slope analysis and turn off contours. A new set of input parameters for min max slopes should appear and the contour interval input param would be destroyed. Now we're done with slope analysis and want to switch back to elevation banding and contour display - we need to re-wire the interval input. I think automatic creation of input params is a very good idea. They shouldn't be automatically removed, though. Rather, we should allow users to keep them wired as long as they are switching between different analysis modi, and remove manually via the zoomable interface (clicking on the small minus when no longer needed). Thoughts? |
Hmm, I guess in that case a rule along the lines of 'never remove optional input parameters unless they have no inputs' could work, as you suggest. That, at least, keeps the first-run experience clean as complexity is only ever built up over time. Definitely in need of a prototype though — I'm not sure, for example, how that kind of dynamic parameter persists between opening/closing a definition. |
Sounds good. Would you explore this further as part of your experiments? |
Took a quick stab at user-defined color ramps. Works all right, but I'm pretty sure the code behind it could be cleaner. The amount of sliders is growing :) To do:
|
Just a heads up that I've relabelled this issue to track the broader aim of having a series of config/settings components (rather than the specific goal of the right-click menus). |
Closing this since the majority of the above discussed ideas have been addressed in separate issues/PRs. |
It is possible for Grasshopper components to offer toggles in their right-click 'contextual' menus. While in general it's useful for parameters to be explicit as inputs, I think there's a case to be made that the different options for coloring the mesh made by Sandworm would be better placed within a menu rather than a parameter with a magic number. Doing so would be easier to interact with and I don't think there is an obvious use case for the color style to be parametrically controlled. Implementation is pretty simple and described here.
If implemented, the baseline options could include:
Additional options that could be presented as toggles within that same list:
This implementation wouldn't provide a means to more explicitly control any parameters in the above options. Some currently-hardcoded parameters (like max depth/height) wouldn't apply to all of them either. A dedicated 'color options' component, as used by Ladybug and the like, could potentially be used for this kind of flexibility if/when the defaults need to be more explicitly controlled. The other option might just be to have separate components for each flavour of analysis and then directly expose relevant configuration options as parameters.
The text was updated successfully, but these errors were encountered: