-
Notifications
You must be signed in to change notification settings - Fork 118
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
Add OfxParamTypeStrChoice
, a string-backed enum of choices
#129
Comments
Is there a property to query if the host supports this?
…On Fri, Oct 6, 2023, 6:29 PM Greg Cotten ***@***.***> wrote:
Summary
Currently there is no way to update a list of choices except by appending
them to the end of the list. This is because ChoiceParam simply remembers
what integer index was selected by the user.
For UX reasons, plugin developers sometimes need to be able to provide
alphabetically sorted lists (or just a curated order) of choices for a user
to pick through. Unfortunately ChoiceParam doesn't fulfill this
particular problem. DaVinci Resolve defines an extension regrettably
officially namespaced OfxParamTypeStrChoice with the following extensions:
/** @brief String to identify a param as a Single string-valued, 'one-of-many' parameter */#define kOfxParamTypeStrChoice "OfxParamTypeStrChoice"
/** @brief Set a enumeration string in a choice parameter. - Type - UTF8 C string X N - Property Set - plugin parameter descriptor (read/write) and instance (read/write), - Default - the property is empty with no options set.This property contains the set of enumeration strings corresponding to the options that will be presented to a user from a choice parameter. See @ref ParametersChoice for more details..*/#define kOfxParamPropChoiceEnum "OfxParamPropChoiceEnum"
/** @brief Indicates if the host supports animation of string choice params. - Type - int X 1 - Property Set - host descriptor (read only) - Valid Values - 0 or 1*/#define kOfxParamHostPropSupportsStrChoiceAnimation "OfxParamHostPropSupportsStrChoiceAnimation"
Motivation
Fills a UI gap for plugin developers.
Problem
Plugin developers need to update their plugins with the latest and
greatest features which can include adding new entries to a choice param.
Currently they are stuck adding the entry to the end of the choice param
(not to mention *removing* an old entry).
Impact
Purely additive.
Documentation Impact
A new param type, probably OfxParamTypeStrChoice since it's already used
by Resolve.
Stakeholders
Everyone, I hope!
—
Reply to this email directly, view it on GitHub
<#129>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM64AQZKW3WBTSEZKA4HTTX6CH5RAVCNFSM6AAAAAA5WOY6QKVHI2DSMVQWIX3LMV43ASLTON2WKOZRHEZTCMBUGIYTGNY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Not in the Resolve extension, but obviously could add! |
I guess the idea is you try to add it and then fall back to them other
choice list if the host returns an error? So I suppose the query isn't
really necessary.
…On Sat, Oct 7, 2023, 9:16 AM Greg Cotten ***@***.***> wrote:
Not in the Resolve extension, but obviously could add!
—
Reply to this email directly, view it on GitHub
<#129 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM64AX6GWZHTSJRL4Z7MSTX6FP5RAVCNFSM6AAAAAA5WOY6QKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJRG4ZDGOJSHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Just a simple example of the issue plugin developers currently face. Imagine a nice alphabetized list of choices in a drop down menu:
In version 1.1.0 of the plugin, the user selected "B", and the host remembers that by saving the index selected as Now it's been a few months and we've decided to add a great new feature "Aa" to the list for version 1.2.0. Currently, in order to preserve the user's plugin state, we would need to add this item to the bottom of the list:
That's fine, but not great for our users - they're used to traversing this particular drop-down menu in alphabetical order, and now we've sullied it! It would be much better for the list to look like:
|
A key thing to note that I didn't effectively communicate initially: StrChoiceParam should have 2 N-string arrays: kOfxParamPropChoiceEnum - a list of strings that could be some sort of non-user-facing internal identifier This allows the plugin developer to have constant implementation-detail enum identifier strings while having a pretty display name that they can change between releases for UI/UX reasons. |
OfxParamTypeStrChoice
, a string-backed enum of choices
Would it not be better to have integer identifiers instead of string identifiers? That way things can be kept backwards compatible with the current Choice parameter type. There can be an optional property to specify the identifiers to use instead of the indices. It would also save some string compares to check values. |
While I like this idea, one of the inspirations for adding this feature as specified is to automagically add host support for a large set of plugins that are currently already using this feature in Resolve. |
Need to define behavior for host (what to display in menu) when an old entry does not exist |
Resolve's behavior is to display an empty string (!!!) |
Revised proposal: Extend ParamTypeChoice with an integer key |
To elaborate on my previous comment: the idea is to add an optional int X N property to the existing "OfxParamTypeChoice" parameter, named something like "OfxParamPropChoiceIdentifiers" or "OfxParamPropChoiceValues". This property should have the same number of values and ordering as the "OfxParamPropChoiceOption" property. If this property is present then instead of the index in "OfxParamPropChoiceOption" the value of "OfxParamPropChoiceIdentifiers" at that index is used as the value of the option parameter. |
I thought about this some more and why can't it just be an optional "order" list, the same length as the choice list, that has the order #s for the choices. |
Well it could, but I'd say that would make both the plugin and host code pretty messy. |
I think the main issue is some hosts don't store string values, only integer indeces for choice/option parameters. |
I think Guido's proposal of the plugin providing the int value to be stored is simpler than adding a new param type. It also means hosts can still use integers as the stored value of choice params so it's probably really easy to implement. I think it's stronger than using an index-order array too. Here's @fxtech 's example reworked using Guido's scheme: Then to add The host displays the choices in the order specified by the option property array, and the value saved/loaded in the project is the The default value of the choice param should be interpreted as a member of the For compatibility, hosts can assume that a plugin that doesn't specify a The only remaining question is what to do about values that are removed in a plugin version. I suggest that a host which encounters a saved value that no longer exists (either because it's off the end of an implicit value array or missing from an explicit one) should use the default value of the param. And if the default value is nonexistent, use 0. That's my idea anyway. |
Except for hosts that don't support the OfxParamPropChoiceValue property. Once a new item is inserted in the list, the wrong options could be used. You could also sunset obsolete values with an order list in a backward-compatible way as well - just mark ones that should not appear with an order of -1. Hosts that don't support the order list would continue to display all of the options as before, but this is surely safer than having old options just go away entirely, to be replaced with a new potentially arbitrary default. |
Yes, that's the situation today. Wrong items get used if an item is inserted in the middle. With this proposal, a plugin can detect whether You make an excellent point about the need to "sunset" obsolete values. Let me see if I understand your idea, @fxtech . The And just to flesh it out, the default But all that leads to a question: when a host loads a plugin with a sunsetted option as the saved value, what should it display? Reset to default? Here's a suggestion: take the negative of A nice property of your version, @fxtech, is that when a plugin adds a new option C, it adds it at the end as usual, We should specify that behavior is undetermined if What do folks think? |
Yes that's a good summary @garyo. What I like about this proposal is it simplifies things on both sides - it's completely backward compatible for host vendors and a plugin vendor doesn't need to check for the support at all. |
Presumably the plugin has to have some idea what it wants to do here, right? Some new option that it wants users to be upgraded to, even if not 100% compatible?
That's a reasonable option as well -- then the plugin can decide what to do at runtime. Host folks, does that seem doable? |
I find |
I'm on board with @Guido-assim 's proposal for OfxParamPropChoiceValue. I'll implement this in the next Silhouette release. |
Summary
Currently there is no way to update a list of choices except by appending them to the end of the list of choices. This is because
OfxParamTypeChoice
simply remembers what integer index was selected by the user.For UX reasons, plugin developers sometimes need to be able to provide alphabetically sorted lists (or just a curated order) of choices for a user to pick through. Unfortunately
OfxParamTypeChoice
doesn't provide a solution to this particular problem.The new
OfxParamTypeStrChoice
should have 2 N-string arrays:kOfxParamPropChoiceEnum
- a list of strings that could be some sort of non-user-facing internal identifierkOfxParamPropChoiceOption
- a corresponding list of strings (same size askOfxParamPropChoiceEnum
) of "pretty" user-facing display name stringsThis allows the plugin developer to have constant implementation-detail enum identifier strings while having a pretty display name that they can change between releases for UI/UX reasons.
DaVinci Resolve already defines an extension:
Motivation
Fills a UI gap for plugin developers.
Problem
Plugin developers need to update their plugins with the latest and greatest features which can include adding new entries to a choice param. Currently they are stuck adding the entry to the end of the choice param (not to mention removing an old entry).
Impact
Purely additive.
Documentation Impact
A new param type, probably
OfxParamTypeStrChoice
since it's already used by Resolve.Stakeholders
Everyone, I hope!
The text was updated successfully, but these errors were encountered: