Plugin developers wishlist

[Tom Palmer]

This issue is a catch-all for things the plugin devs would like to see in 2.1 …

[Dale Ghent]

• Expose any remaining public driver properties and methods that are not currently in their associated interfaces or mediators
• Policy or mechanism to protect against or allow different versions of assemblies that might also be used by NINA itself or other plugins (ie, app domains and avoiding potential for DLL collisions)
• Some way for plugins to be able to test for the presence and use each other’s functionality. Perhaps potential for a hairy mess here.
• Device drivers as plugins, including plate solvers

• Extend pluggable interfaces to other areas of the app:

  • Image metadata. This would allow plugins to implement their own file patterns and image headers
  • …

‌

[Tom Palmer]

I’d like to see the following capabilities in 2.1 for plugin devs:

• Today, we have access to a number of mediators that can be injected into a plugin, for example IImageSaveMediator. It would be nice to be able to get notified of other types of events occurring within the application. Each event might have additional details specific to the type.

  • Equipment connects/disconnects
  • Sequence start/pause/stop
  • Scope Unpark/Slew/Park
  • Center/plate solve
  • AF
  • MF
  • etc

• It would be nice to also get notified about details happening within a running sequence like instruction start/waiting/finish, instruction errors, etc

• Other kinds of errors might be more serious like AF or MF fails - like to hear about those.

Thanks!

[Stefan B]

Extendable MetaData, SequenceFailureEvents and File Patterns are available for 2.0.1

[Stefan B]

Following items are available in 2.0.2:

• Device drivers as plugins
• Events for AfterDither, BeforeMeridianFlip, AfterMeridianFlip added

‌

[Stefan B]

• GetDevice() in mediators is available to access specific drivers.

• Raising connected/disconnected events is available in 3.x

  • more events will be introduced over time

‌