mirror of
https://github.com/ynput/ayon-core.git
synced 2025-12-25 21:32:15 +01:00
103 lines
5.6 KiB
Markdown
103 lines
5.6 KiB
Markdown
# Pype modules
|
|
Pype modules should contain separated logic of specific kind of implementation, like Ftrack connection and usage code or Deadline farm rendering.
|
|
|
|
## Base class `PypeModule`
|
|
- abstract class as base for each module
|
|
- implementation should be module's api withou GUI parts
|
|
- may implement `get_global_environments` method which should return dictionary of environments that are globally appliable and value is the same for whole studio if launched at any workstation (except os specific paths)
|
|
- abstract parts:
|
|
- `name` attribute - name of a module
|
|
- `initialize` method - method for own initialization of a module (should not override `__init__`)
|
|
- `connect_with_modules` method - where module may look for it's interfaces implementations or check for other modules
|
|
- `__init__` should not be overriden and `initialize` should not do time consuming part but only prepare base data about module
|
|
- also keep in mind that they may be initialized in headless mode
|
|
- connection with other modules is made with help of interfaces
|
|
|
|
# Interfaces
|
|
- interface is class that has defined abstract methods to implement and may contain preimplemented helper methods
|
|
- module that inherit from an interface must implement those abstract methods otherwise won't be initialized
|
|
- it is easy to find which module object inherited from which interfaces withh 100% chance they have implemented required methods
|
|
|
|
## Global interfaces
|
|
- few interfaces are implemented for global usage
|
|
|
|
### IPluginPaths
|
|
- module want to add directory path/s to avalon or publish plugins
|
|
- module must implement `get_plugin_paths` which must return dictionary with possible keys `"publish"`, `"load"`, `"create"` or `"actions"`
|
|
- each key may contain list or string with path to directory with plugins
|
|
|
|
### ITrayModule
|
|
- module has more logic when used in tray
|
|
- it is possible that module can be used only in tray
|
|
- abstract methods
|
|
- `tray_init` - initialization triggered after `initialize` when used in `TrayModulesManager` and before `connect_with_modules`
|
|
- `tray_menu` - add actions to tray widget's menu that represent the module
|
|
- `tray_start` - start of module's login in tray
|
|
- module is initialized and connected with other modules
|
|
- `tray_exit` - module's cleanup like stop and join threads etc.
|
|
- order of calling is based on implementation this order is how it works with `TrayModulesManager`
|
|
- it is recommended to import and use GUI implementaion only in these methods
|
|
- has attribute `tray_initialized` (bool) which is set to False by default and is set by `TrayModulesManager` to True after `tray_init`
|
|
- if module has logic only in tray or for both then should be checking for `tray_initialized` attribute to decide how should handle situations
|
|
|
|
### ITrayService
|
|
- inherit from `ITrayModule` and implement `tray_menu` method for you
|
|
- add action to submenu "Services" in tray widget menu with icon and label
|
|
- abstract atttribute `label`
|
|
- label shown in menu
|
|
- interface has preimplemented methods to change icon color
|
|
- `set_service_running` - green icon
|
|
- `set_service_failed` - red icon
|
|
- `set_service_idle` - orange icon
|
|
- these states must be set by module itself `set_service_running` is default state on initialization
|
|
|
|
### ITrayAction
|
|
- inherit from `ITrayModule` and implement `tray_menu` method for you
|
|
- add action to tray widget menu with label
|
|
- abstract atttribute `label`
|
|
- label shown in menu
|
|
- abstract method `on_action_trigger`
|
|
- what should happen when action is triggered
|
|
- NOTE: It is good idea to implement logic in `on_action_trigger` to api method and trigger that methods on callbacks this gives ability to trigger that method outside tray
|
|
|
|
## Modules interfaces
|
|
- modules may have defined their interfaces to be able recognize other modules that would want to use their features
|
|
-
|
|
### Example:
|
|
- Ftrack module has `IFtrackEventHandlerPaths` which helps to tell Ftrack module which of other modules want to add paths to server/user event handlers
|
|
- Clockify module use `IFtrackEventHandlerPaths` and return paths to clockify ftrack synchronizers
|
|
|
|
- Clockify has more inharitance it's class definition looks like
|
|
```
|
|
class ClockifyModule(
|
|
PypeModule, # Says it's Pype module so ModulesManager will try to initialize.
|
|
ITrayModule, # Says has special implementation when used in tray.
|
|
IPluginPaths, # Says has plugin paths that want to register (paths to clockify actions for launcher).
|
|
IFtrackEventHandlerPaths, # Says has Ftrack actions/events for user/server.
|
|
ITimersManager # Listen to other modules with timer and can trigger changes in other module timers through `TimerManager` module.
|
|
):
|
|
```
|
|
|
|
### ModulesManager
|
|
- collect module classes and tries to initialize them
|
|
- important attributes
|
|
- `modules` - list of available attributes
|
|
- `modules_by_id` - dictionary of modules mapped by their ids
|
|
- `modules_by_name` - dictionary of modules mapped by their names
|
|
- all these attributes contain all found modules even if are not enabled
|
|
- helper methods
|
|
- `collect_global_environments` to collect all global environments from enabled modules with calling `get_global_environments` on each of them
|
|
- `collect_plugin_paths` collect plugin paths from all enabled modules
|
|
- output is always dictionary with all keys and values as list
|
|
```
|
|
{
|
|
"publish": [],
|
|
"create": [],
|
|
"load": [],
|
|
"actions": []
|
|
}
|
|
```
|
|
|
|
### TrayModulesManager
|
|
- inherit from `ModulesManager`
|
|
- has specific implementations for Pype Tray tool and handle `ITrayModule` methods
|