Plugin.Options File += ValueModified Event

Deadline
1

Hi,
Potential Feature Requests for Deadline Scripting Enhancement, if possible?

Got 2 similar situations in Deadline scripting in the Plugin.Options File:

(a) I am unable to link 2 or more UI elements. ie: Change the value in 1 or more UI elements and have a “.ValueModified += Event Function to handle Changed Value”. For example, enable 1 checkbox in a Plugin Job Properties and it causes another UI element such as another checkbox to be disabled (as you can’t have setting #2 enabled AND also have setting #1 also enabled at the same time, kind of logic…)
(b) The ability to create an element which changes the value of multiple other UI elements at the same time. ie: A drop-down “Presets” list element, which once selected, updates a number of other UI elements values at the same time. (I think this second issue would be fixed effectively by having a “Changed Event” driven solution in the Options.File, but I provide the example, so you can understand what I am trying to achieve).

Finally, it would be nice to have script control over the width of ALL the UI elements when displayed in the job plugin properties tab. Sometimes the default UI width is complete overkill and sometimes I want to have a long label string identifying the UI element, but can’t as the width of the UI element is a default width! Of course, the tooltip does indeed come to the rescue when the cursor hovers over the UI element but its not ideal.

Thanks,
Mike

2

Hi Mike,

We designed the options file allow for the simple creation of a UI to edit the values of those options, but we understand that this results in a loss of flexibility in some areas. We can add this to the wishlist. We have two options:

  1. Changing how the options file works, since this type of functionality can’t be achieved with a simple ini file. However, we would like to avoid this to maintain plugin compatibility.

  2. Building an more complex (but optional) layer on top of the existing options file. This would probably be the way to go.

I’m thinking that if we go with (2), the options file would have pointers to either the original plugin.py file, or another python script that would house the logic for modifying values, and perhaps even custom UI editing (enabling/disabling controls, changing their size, etc).

Cheers,

  • Ryan
3

Thanks Ryan.
I totally understand and agree with your first point :slight_smile:
Yeah, Option 2 sounds like the best approach. Perhaps, “Options.py” as an optional py script that can be present in a plugin directory?
I like the idea of keeping the “Options.py” separate from the main “plugin.py”…My custom plugin.py script is getting big enough already!
Thanks,
Mike