Add/remove component parameters depending on zoom level dynamically

Hello,

is there a way of adding/removing parameters dynamically depending on the canvas zoom level? I am trying to expose more parameters upon zooming in on a component.

Something along the lines

override OnPaintComponent(GH_Canvas ghC)

{

//somehow find my pManager

GH_Component.GH_InputParamManager pManager = this.pManager;

if (Grasshopper.CentralSettings.CanvasZuiZoomLevel < Grasshopper.GUI.Canvas.GH_Canvas.ZoomFadeHigh)
{

pManager.AddBooleanParameter("param", "P", "my new parameter", GH_ParamAccess.item);
}

if (Grasshopper.CentralSettings.CanvasZuiZoomLevel < Grasshopper.GUI.Canvas.GH_Canvas.ZoomFadeHigh)
{

pManager.RemoveBooleanParameter("param", "P", "my new parameter", GH_ParamAccess.item);
}

}

I think this works "manually" by implementing the IGH_VariableParameterComponent interface, but does it work dynamically? Has anyone had success doing that?

Thanks for any pointers!

Replies to This Discussion

Permalink Reply by David Rutten on July 29, 2014 at 10:43am

Although you can override the display as much as you like, you probably shouldn't be actually adding or removing parameters based on the view.

It doesn't sound easy though, and it does sound confusing. Users won't be expecting this behaviour unless you tell them explicitly it can be done...

Can you provide a quick sketch of what you want to achieve exactly?

David Rutten

david@mcneel.com

Permalink Reply by Daniel Gebreiter on July 29, 2014 at 12:05pm

Hi David,

I've got a few components which just have too many inputs to look neat on the canvas.

Moreover, many of them are optional to the user and only required in special cases.

Consider a custom finite element line with

start point

end point

cross-section (optional)

local coordinate system (optional)

some property (optional)

some other property (optional)

additional settings (optional)

etc

Now in 99% of the cases, users will only specify the first 4 parameters and leave the others blank. I'm not a huge fan of to many inputs so to clean up the canvas/components, I thought about exposing the optional parameters only upon zooming in on the component.

So far I've sometimes added a secondary component with more inputs to specify a list of additional settings (similar to the "settings" panel that exists/existed in Kangaroo), but this I find rather messy.

Alternatively I guess I could quite happily live with exposing the additional parameters at the click of a button. This I can do with the ZUI as it is written? I still need to get my head round what's what in this happy world of the canvas' third dimension...

Permalink Reply by Daniel Gebreiter on July 29, 2014 at 1:36pm

and voila a screenshot of the intended expansion functionality

Initially I thought zooming in would be nice to expose (or unhide) the optional parameters. But now I agree you might be right, an arrow button or similar would be nice to expose parameters which are often unused...

Of course this raises the questions as to what happens when input parameters are connected to something and the list is collapsed again - but maybe the ones with active connections are simply not collapsed back?

On the left the collapsed component, on the right the fully exposed version.

Attachments:

expand.jpg, 176 KB

Permalink Reply by David Rutten on July 29, 2014 at 1:51pm

It would be fairly trivial to make the component 'unfold'. You'd still have to override the attributes, but I think most of the drawing and layout can be done by calling available methods.

Doing it through the menu allows you to get away without overriding attribute display, layout and mouse-handling. Perhaps that's a good place to start, then override the attributes later if you still want to.

I can upload an example of this probably later tonight.

David Rutten

david@mcneel.com

Permalink Reply by David Rutten on July 29, 2014 at 2:25pm

The attached code adds or removes parameters from a component menu.

I didn't set a message yet, that should probably be done to signal to the user there is a menu option they should care about.

David Rutten

david@mcneel.com

Attachments:

FoldingParameters.cs, 4 KB

Permalink Reply by Daniel Gebreiter on July 29, 2014 at 3:59pm

Nice, thanks.

I've modified it such that it can deal with two open issues.

1. Inputs with sources are no longer removed when collapsing.

2. Inputs where a value had been set manually lost this value upon collapsing. This manually set value is now restored upon unfolding.

However, I've had to include a permanent list of parameters in the component, not sure if that's best practice. Wouldn't it be nicer to have a "Visible" flag with parameters where they would simply be omitted from the list (if certain permitting conditions are met), rather than registering/unregistering them entirely?

There is also an issue with the order of inputs changing when some are collapsed and some aren't. This could be fixed with a bit of brain though.

Sending a message could be done with GH_RuntimeMessage for now, but I might look into providing a little arrow button like I had in my sketch when I have time.

Thanks a million, you have already brought me a whole lot further with this!

Attachments:

Expand.cs, 5 KB

Permalink Reply by Andrew Heumann on July 29, 2014 at 1:54pm

As a user I think multiple zoom levels would be extremely confusing. For complex options consider some of the other ways of dealing with this, some of which are a bit more "grasshopper-style":

1. have a regular component and an "expanded" or "advanced" component with this extended functionality

2. have some of the custom optional parameters entered in a settings component (like mesh brep + custom mesh settings)

3. Embed some of these options (if they do not need to be dynamic inputs) as component menu items (like "maintain paths" in the tree branch component)

4. (not 100% sure this last one is possible but it should be...) use a component menu as in 3. to show/hide advanced inputs. As you say the problem of hiding inputs with connections is a bit tricky but I think the most intuitive behavior is to leave the ones with connections always visible as you describe.

Permalink Reply by Lorenzo Greco on July 29, 2014 at 1:59pm