# 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