use gui selector with new NanoVG option

[dromer]

in preparation for the new GUI generator. still a draft for now

[timothyschoen]

One small design note: I think calling the two GUI modes "ImGUI" and "NanoVG" doesn't clearly communicate the difference between them. I feel like that's communicating a (usually irrelevant) technical detail instead of the functional difference.

Perhaps "Parameter GUI" and "Patch GUI" or something like that would be better?

[dromer]

Those monikers have literally no meaning though.

I'm fine with using more clear names that users can understand, but they both have parameters so I don't understand the suggestion :P

[timothyschoen]

Isn't the ImGUI interface tied to hv_param? That's where the name came from, but I'm all for finding something better

[dromer]

All exposed parameters are tied to @hv_param. This is the only method that we can connect the DSP to the generated plugin interface. The NanoVG implementation is no different. Except the receiver is embedded inside of the GUI object.

The library difference is very significant though and I'd rather convey correct information to users than put it behind some obscure nomenclature.

[timothyschoen]

The library difference is very significant though and I'd rather convey correct information to users than put it behind some obscure nomenclature.

I agree it's very different from a technical perspective. But from the user's perspective, the difference is really "am I getting rows of sliders/toggles" vs "am I getting a UI that looks like my patch". Nothing about ImGUI vs NanoVG communicates that to the user. Even if they know what ImGUI and NanoVG are (I assume most users won't), the primary difference is how we use the frameworks, more so than the frameworks themselves. You could, if you wanted to, implement the current ImGUI style GUI with NanoVG for example. So even if the users were to Google these frameworks, it would still tell them nothing about the effect it has on their plugin export.

So you are left with the choice:

• Communicate what makes it functionally different, and rely on documentation to communicate the technical difference
• Communicate what makes it technically different, and rely on documentation to communicate the functional difference

My preference leans strongly towards the first option. Especially because the technical difference only matters if the user is going to customize the source code by hand.

If you're really dead set against changing this, I can live with it. But if I put myself in the shoes of a user, I would find it a bit confusing.

[dromer]

I'm not dead set against it, but I want it to be clear and not obscure :P
(and yes, the frameworks are also obscure if you don't know what they are)

Both UIs are "generated" so that's not a good term either. I don't know how to discern these other than the frameworks that they use.

[dromer]

Perhaps Generic vs Custom ?

One reason against using Patch is that users might think they can use patching features in the UI which is explicitly not possible. So we shouldn't steer users into thinking this is the case.

[dromer]

We could add the framework in parenthesis for some clarity/specificity maybe. If it fits in the dropdown.