plugins
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
plugins [2018/05/19 13:42] – James Sentman | plugins [2023/06/06 14:06] – James Sentman | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | =====The XTension Plugin API===== | + | =====The XTension Plugin API v2===== |
- | **NOTE: | + | **NOTE: |
\\ | \\ | ||
- | |||
- | Download sample plugin [[http:// | ||
\\ | \\ | ||
- | Introduced in XTension version 9.3 you can now create new interfaces | + | Introduced in XTension version 9.3 you can now create new plugins |
- | \\ | + | |
- | Complex dynamic interfaces | + | |
- | {{ : | + | |
- | For Unit level configuration you can embed configuration for individual controls on the first tab of the [[xtension_manual: | + | |
- | {{ : | + | |
- | Lastly there are 2 hooks for creating custom | + | |
- | {{: | + | |
- | \\ | + | |
- | For less used control options your plugin | + | |
- | {{: | + | |
- | Lastly | + | |
- | < | ||
- | tell xInterface “name of plugin interface” to doDefinedHandler( withData, andMoreData) | ||
- | </ | ||
- | If your Python script defines | + | ====Plugin Custom Interfaces==== |
- | \\ | + | |
- | The unit level access | + | You can create plugin interfaces in the Edit Interface dialog for individual interface level settings. You can add controls to the Edit Unit dialog for unit level interfaces and you can also add controls to the advanced and simple unit control popups for actually sending commands to a unit. All controls are defined in the info.json file that must accompany the application. You can create them by hand or better yet using the interface builder app linked to in that section of the wiki. On my todo list are other places that interfaces can be inserted |
+ | |||
+ | While there is no current interface | ||
+ | |||
+ | ====Plugin Units vs Database Sharing==== | ||
+ | There are 2 modes that a plugin can operate in. The regular mode is for providing an interface to some physical device. This lets you create units in XTension that are linked to a specific plugin instance. You do not have access | ||
+ | |||
+ | You can add the Database Sharing option to your info.json file and in that case the user will be presented with options for choosing what units will be sent to your interface instance. This is for plugins that might wish to provide a bridge to some other functionality like sharing units to an Alexa or HomeKit or just creating a PubSub or MMQT interface to portions of the database. As of V2.0 of the API you can ask for Units and Global Scripts to be shared. The user will be able to select either to share the entire database or to select from lists of Units and select individual Global Script. This is the interface that is used for the built in [[supported_hardware: | ||
+ | |||
+ | ====Sharing well known ports or UDP sockets with other plugins==== | ||
+ | This is particularly a problem with programs that want to respond to or listen for things like UPNP packets. Only one program on a machine can be listening the specific UDP socket that UPNP happens over. XTension gets around | ||
+ | |||
+ | ====Contextual Menu Handlers==== | ||
+ | You can add contextual menu handlers to any unit through your plugin. You can define these in the info.json handler for the specific unit type. When the user selects them an execute handler command will be sent to your plugin | ||
+ | |||
+ | ====Adding Script Commands==== | ||
+ | While Python is used for plugin development, internal to XTension AppleScript is used as the scripting language. XTension supports the AppleScript Object Model and any unit may be wrapped in a tell block. There are many commands and settings that can be sent to a unit this way. Any commands received through such a script that are not one of the reserved commands or well known handlers that are built into XTension | ||
< | < | ||
- | | + | tell xUnit “name of a plugin unit” to doSomethingPluginSpecific( withSomeData) |
+ | |||
+ | tell xInterface “name of the plugin instance” to doAPluginTask( withSomeData) | ||
</ | </ | ||
- | \\ | + | |
- | This should provide | + | ====Installing and Un-Installing Plugins==== |
- | \\ | + | XTension provides a mechanism to install |
+ | |||
+ | The XTension | ||
+ | |||
+ | ====Blocking and Non-Blocking Functions==== | ||
+ | Since the plugin runs as a separate process from XTension you can use any combination of blocking or threaded operations without worrying about blocking the host app. If you perform a blocking action in response to a received command from XTension that should be bumped out to a separate thread to await it’s return. XTension will regularly send a ping to your interface that needs to be returned or it will recycle your interface thinking it had hung up. You should not block in any event received from XTension. | ||
+ | |||
NEXT: [[plugins: | NEXT: [[plugins: |