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
Provide support for a parent plugin that has all its values applied alongside the actual plugin. For example, if we look at themes, the exact same logic is applied across at least 6 files, for displays the same logic is applied to a greater and lesser extent across many of the plugins too. In fact, there is an amount of duplication in many of the plugins.
I propose the simplest solution to start with that would provide a new optional element at the top level called parent, it would hold the name of a plugin template from the templates directory. This would ensure anyone looking at the plugin structure would not mistake a template for a plugin. It would in every other way be a plugin. Maybe a rule would be that it had to end with Template, eg it would be in templates/ColorThemeTemplate.xml to ensure it is not mistaken.
During the loading, the top level fields SupportedPlatforms, Description, Documentation, RequiredLibraries, ImageFile would all be ignored. They make no sense in the plugin context and should just be used to document how the template can be used.
The properties are to be additive, IE the list of properties becomes parentProperties + leafProperties.
Any applicabilityDefs will be added to the list of applicabilities.
Any source files will be added to the list of source files, as will any replacements, they will all be global
Any include files will added to the list of include files. To ensure order, use priority, do not rely on ordering
Global variables will be defined parent first, then plugin.
Functions, like plugins will appear in the source parent first, then plugin.
Theme plugins could be halved in size, and others could be significantly simplified and duplication reduced.
With this a hypothetical theme plugin may look like:
Provide support for a parent plugin that has all its values applied alongside the actual plugin. For example, if we look at themes, the exact same logic is applied across at least 6 files, for displays the same logic is applied to a greater and lesser extent across many of the plugins too. In fact, there is an amount of duplication in many of the plugins.
I propose the simplest solution to start with that would provide a new optional element at the top level called
parent
, it would hold the name of a plugin template from thetemplates
directory. This would ensure anyone looking at the plugin structure would not mistake a template for a plugin. It would in every other way be a plugin. Maybe a rule would be that it had to end with Template, eg it would be intemplates/ColorThemeTemplate.xml
to ensure it is not mistaken.SupportedPlatforms, Description, Documentation, RequiredLibraries, ImageFile
would all be ignored. They make no sense in the plugin context and should just be used to document how the template can be used.Theme plugins could be halved in size, and others could be significantly simplified and duplication reduced.
With this a hypothetical theme plugin may look like:
The text was updated successfully, but these errors were encountered: