Component config for params/shots

[cale-bradbury]

I feel it makes sense to focus any custom editor type defining to the config file. Would be great if we could let the config creator have access to set any css type things as you can in regular html (to set a specific width/height etc).

Possible options, we could replace the current json setup with a more html style, and pull the info we need from the element

<Row height=150>
    <Param 
        key="foo"
        title="Foo"
        defaultValue=.5 
    />
</Row>

Or place special objects within the json that are detected while we scan for params/shots, and trigger another scan on its children

params:[
    {key: 'bar', title: 'Bar'},
    {
        meta: 'row',
        height: 150,
        children:[ 
            {key: 'foo', title: 'Foo'}
        ]
]

Thirdly we could just add some info in the current param object, probably still want to have a meta object of some sort in order to have things like section header labels etc (also the question of what to do when a row is only set for some params)

params:[
     {key: 'bar', title: 'Bar', row:0, type:'color', drawer: 'GradientSlider'},
     {key: 'foo', title: 'Foo', row:1, height:150}
     {key: 'ack', title: 'Ack', row:1} //rows height comes from the tallest element
]

Would love to know your thoughts on what makes sense to implement. Feel that custom editor control is going to be important as sketches start getting passed around/shared publicly. I think this would be a good thing to have figured out by 0.5

[funwithtriangles]

I'm a little confused as to what is being described here. Are you suggesting the capability of setting specific column widths/heights for params and shots? Also extra stuff like collapsible sub sections for sketches, etc? Sounds sensible to me!

What do you mean by "custom editor"?

[cale-bradbury]

So I'm thinking about giving a sketch creator more control over how the params/shots appear in hedron, for example, I was thinking of making a generic 5x5 convolution filter post effect, in which case I would want 5 params per row (and ideally be able to make each one a square and slider-less to appease my design-brain)

By custom editor, I mean allowing customization beyond the default way params/shots are drawn, feeling like this could be achieved with some css type stuff for sizing, and a drawer tag in params/shots that would change how it is displayed (ie, sliderless params that are only text boxes, a sweepable gradient editor instead of a color picker (once we get more data types in))

[funwithtriangles]

So to summarise, there are two separate things going on here:

Param layout (Rows / Columns) Using the config file, users can define the size of params and shots in terms of rows/columns.

Custom styles for params Params should be able to come in different forms. For instance, a sketch author may not want a param to display a slider.

A more complex example might be that of a Vector3 param type (which doesn't exist yet). This param may want to be represented as XYZ, or HSL, etc. Having completely different components for this param could be useful.

Possible syntax:

params:[
   {
      key: 'bar', 
      title: 'Bar',
      component: 'FooComponent', // The author has a choice of different components
      componentProps: {
         slider: 'hidden' // For smaller changes within the component
      }
   },
]

[funwithtriangles]

The rows/cols stuff should happen after this is fixed: https://github.com/nudibranchrecords/hedron/issues/117

[funwithtriangles]

I've split out the layout stuff into a separate issue: https://github.com/nudibranchrecords/hedron/issues/118

[cale-bradbury]

Yeah, perfect, this really is 2 issues, just that they are dealing with the same area.

[funwithtriangles]

A bit more logic to consider:

• Each param type (e.g. float, boolean, vec3) should also have an associated default component associated with it
• Extra components to choose from in the config will only be compatible with certain types. Perhaps it's a one to one association with component and param type? Or maybe a component could be compatible with more than one type? I'm not sure if the latter makes sense.

[funwithtriangles]

This is actually quite a nice modular way to think about how the new param types will work from a React/UI perspective 😄