Cynics at Large The cyin package

Cyin

Indigo 5's plugin interface is structurally sound. You write a Python file declaring a Plugin class. Indigo launches a plugin host process, makes one instance of your Plugin class, and proceeds to bombard it with callback messages. If your plugin messes up, only your own process gets into trouble. (At least that's the theory.)

This is serviceable enough for a first version, but it's hardly convenient for a plugin writer. You end up writing a single class, Plugin, and stuffing all the Indigo-related code into it. Even while Indigo is filled with object-like concepts - devices, actions, events - in Indigo's plugin interface they're reduced to string names and dictionaries. Even the UI model is reduced to a few callbacks stuffed with useful information, but nary enough continuity.

What to do? I've written a Python package, called cyin (cynical indigo), that refashions the environment for writing Indigo plugins. Fundamentally, cyin requires you to create a Python class for each device, action, and event in your plugin, and creates instances as Indigo talks about them. Cyin.Plugin intercepts calls from Indigo and dispatches them to methods in those various classes, so that your Plugin class becomes quite literally empty - it contains declarations of plugin preferences, code for setting up global state, and perhaps some odds and ends like filter functions.

Cyin is documented, in classic Pythonic fashion, in its source. Open up a plugin and take a look...


About This Area 29 Oct 2019 19:52