Custom Launcher

Before you start

Here we go through how to create a custom launcher plugin for AKL. We assume you already know all the basics about how to code with python, how to create kodi addons and how to work with git. On this page we only go in to the specifics about the needed code, so if not prepared, start here.

Code examples

A good example is the default plugin for AKL. Get the code here. We will refer to this codebase.

The launcher base class: LauncherABC

Although it is completely possible to code everything yourself the way you like, there is some code in module package that can make it easier. You will need to create your own implementation of the LauncherABC class which you can import from akl.launchers from the script.akl.module package.

When extending this class you will need to implement the several abstract methods. Some are for general information, some for configuring the launcher for a specific case (ROM or collections), some for the actual launching.

Constructor / Initialization

When you create a new instance of the launcher you will need to pass through some arguments to the base class.

def __init__(self,
  launcher_id: str,     # unique id for this instance provided by AKL (empty if new)
  romcollection_id: str,# unique id of the collection being used
  rom_id: str,          # unique id of the ROM being launched or configured
  webservice_host:str,  # host url/ip of the AKL webserve. Will be passed through from AKL when the addon is called
  webservice_port:int,  # host port of the AKL webserve. Will be passed through from AKL when the addon is called
  executorFactory: ExecutorFactoryABC = None,   # Factory class for creating executors  
  execution_settings: ExecutionSettings = None  # Settings for the executor instance

Most of the arguments you can pass through from the sys arguments provided when the addon is called through AKL, see here. But the executor factory and settings should be created by you beforehand. The executorfactory creates Executor instances based on your OS and preferences. The Executor does all the heavy duty work of actually calling external apps or scripts. You can get one through the get_executor_factory function you can import from akl.launchers from the module. Check the code for more details.

General information

These methods will probably be deprecated soon enough and will get the data from the settings file etc.
get_name() : A simple method to give back the 'friendly' name of this addon.
get_launcher_addon_id() : This will return the addon id.

Configuration

These methods are involved in configuring the addon or plugin for a specific ROM or collection. The resulting configuration will be stored in the AKL database for that case and re-used when that specific case is called again.

_builder_get_wizard()
This method is called by the base class when a launcher is being configured. It will expect a wizard, a linked or stacked collection of kodi dialogs that will follow eachother up and guide the user in configuring the launcher usecase. The dialogs are linked through the decorator pattern. The result of going through the wizard is a dictionary of settings that is stored in AKL. Each wizard dialog is associated with a key-value pair of that dictionary. If you need to do more than just simply setting the value for a key there is also support for calling helper methods when a dialog shows or leaves.
The akl module supports many different types of wizard dialogs. Take your pick and link them together.

Here is an example of the default plugin where the users must setup a path to the application and add arguments.

def _builder_get_wizard(self, wizard):    
    wizard = kodi.WizardDialog_FileBrowse(wizard, 'application', 'Select the launcher application', 1, self._builder_get_appbrowser_filter)
    wizard = kodi.WizardDialog_Dummy(wizard, 'args', '', self._builder_get_arguments_from_application_path)
    wizard = kodi.WizardDialog_Keyboard(wizard, 'args', 'Application arguments')

    return wizard