You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the problems-to-be-solved regarding #143 was in regards to maintaining the current behaviour of plug-ins being triggered according to the Selection > Validation > Extraction > Conform pattern.
Compound plug-ins is a potential solution to this problem, while at the same time opening up the door for users to extend upon the behaviour on their own.
Goal
To facilitate grouping of common or related plug-ins during processing.
The typical scenario is when looking to trigger a plug-in upon the completion of a series of other plug-ins; such as "All validators" or "All selectors". Much like it's working currently, but programmable and compatible with an event-driven approach.
definition: Compound, a group\series of plug-ins.
Implementation
Compounds are first defined and then registered with Pyblish.
The name given to the compound is then accessible to the on slot of a plug-in.
classMyPlugin(...):
on="MyCompound::after"
Compounds would form the foundation of the re-implementation of the current system, but in an event-driven way; Validators being a component that encapsulates all plug-ins derived from the Validator superclass, whereas Selectorsbeing the component encapsulating all plug-ins derived from the Selector superclass and so on.
This could then be extended upon to facilitate the creation of arbitrary groups of plug-ins.
# Group plug-ins related to mesh-processing; of any type.compund=pyblish.api.Compound(name="MeshPlugins")
forplugininpyblish.api.discover():
forfamilyinplugin.families:
if"mesh"infamily.lower():
compound.register_plugin(plugin)
pyblish.api.register_compound(compound)
Membership isn’t mutually exclusive. That is, a plug-in may be part of multiple compounds.
This is similar to the objectSet of Maya, or Group of Softimage and facilitates the creation of an unlimited amount of compounds that may be mixed and matched in arbitrary ways.
The text was updated successfully, but these errors were encountered:
Prelude
One of the problems-to-be-solved regarding #143 was in regards to maintaining the current behaviour of plug-ins being triggered according to the
Selection > Validation > Extraction > Conform
pattern.Compound plug-ins is a potential solution to this problem, while at the same time opening up the door for users to extend upon the behaviour on their own.
Goal
To facilitate grouping of common or related plug-ins during processing.
The typical scenario is when looking to trigger a plug-in upon the completion of a series of other plug-ins; such as "All validators" or "All selectors". Much like it's working currently, but programmable and compatible with an event-driven approach.
Implementation
Compounds are first defined and then registered with Pyblish.
The
name
given to the compound is then accessible to theon
slot of a plug-in.Compounds would form the foundation of the re-implementation of the current system, but in an event-driven way;
Validators
being a component that encapsulates all plug-ins derived from theValidator
superclass, whereasSelectors
being the component encapsulating all plug-ins derived from theSelector
superclass and so on.This could then be extended upon to facilitate the creation of arbitrary groups of plug-ins.
Which may then be used as.
Compounds and Overlap
Membership isn’t mutually exclusive. That is, a plug-in may be part of multiple compounds.
This is similar to the objectSet of Maya, or Group of Softimage and facilitates the creation of an unlimited amount of compounds that may be mixed and matched in arbitrary ways.
The text was updated successfully, but these errors were encountered: