Allow extension/source plugin to manipulate other extensions

Allow extension/source plugin to manipulate other extensions

[mikeybanez]

I assigned this to [email protected] for now, so let's revisit and discuss with the core team general improvements to how extensions are handled. And then we can see a clearer schedule for implementing these changes in XSplit.

[matthijskooijman]

One specific usecase I would see for this, is to list and activate macros (which are handled through an extension AFAICS) from an xjs extension.

[matthijskooijman]

Any progress on this?

I see there is an iSourceHtml.call() method that allows calling functions within a source plugin. The docs say "call a pre-exposed function", but I can't find any documentation on how to expose functions. A quick experiment shows that any global javascript functions can be called this way, maybe an example or some additional documentation would be useful?

And is there a way to communicate back from a source plugin (e.g. by raising events)? I can imagine one could abuse the item-changed event that can be caught using Item.on for this, but just changing some unused property (and then using the property value or a subsequent iSourceHtml.call() to figure out the actual event that happened), but it would be nicer if a source plugin could just raise arbitrary events too.

Also, it seems that this interaction only works on source plugins, you cannot call code in an extension plugin, since it has no corresponding item or other object.

[nelson-temporal]

Sorry for the late reply.
But yes you are right, the function should be a global function to be called.
Right now there is no direct way for source to extension communication due to limitations.
Right now Macros listen to events from sources by listening to storage (https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event) events.
This can be seen on Macros' triggers to slide shows.

There is another which is the Broadcast Channel API (https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API) which is where Macros would be headed to.

As you can see both are limited to same origin.
Hopefully this has been helpful to you for now.
I guess the limitations are there for security.
Until then, we are not able to include any generic communication between source to extension to xjs.

[matthijskooijman]

@nelson-temporal Thanks for the suggestions. The same-origin limitation is not a problem for us (all our extensions are local files), so these APIs are indeed ideal to communicate between different source/extension plugins. We tried them, and they work as expected.

For anyone else reading this, the APIs @nelson-temporal links are normally intended to be used to share data and/or communicate directly between different tabs/windows running on the same domain in a normal browser. However, in xsplit, each HTML-based plugin runs in its own context as well, just like multiple tabs in your browser, so they can be used here as well.

These APIs only allow communication with the same origin, which is the combination of protocol and domain that the script runs from. For plugins that are local files, rather than web-hosted files, the origin seems to always be "file://", so all local files can communicate with each other.

As for the APIs, there's:

• Storage, which allows sharing persistent named variables between plugins, and can trigger events when variables change (but not when they are set to the same value as before). Normally, these variables are persistent between browser sessions, I haven't tested whether this is also the case within xsplit (and if so, if the values are stored globally or inside the bpres file).
• Broadcast Channel, which allows directly sending messages over one ore more named channels, which can be processed by anyone who is listening at that moment.

I believe that both APIs allow sharing complex datastructure (i.e. not just strings, but also arrays and objects. Maybe even objects with methods and/or functions, haven't tried that).

I haven't looked at how the Macros plugin uses the storage API, though. @nelson-temporal, is that something that can be inspected somewhere? I was under the impression that the Macros plugin does not have its source available anywhere and the installed plugin cannot be unpacked or inspected, or is this not the case?

[nelson-temporal]

Hi, this is a video where and how you could get the scripts inside triggers and actions of Macros
https://321.show/rARfTWOdndn.

Glad to be of assistance 👍

[matthijskooijman]

Ah, never realized that you could copy existing scripts (and had already forgotten that you could custom scripts). Thanks for the video, maybe macros can be useful in our setup after all. Yet another tool in our toolbox :-)