Pro Motion SDK and Test Unit

@jan.cosmingo,

Could you consider creating a PMNG SDK? This could contain documentation, plugin examples source code and, additionaly, it would really great to have a standalone plugin test unit.

PMNG Plugin Test Unit

The idea of the test unit came to my mind from Altap Salamander, a commercial tool that I bought, which is also extensible via DLL plugins. On its website they offer an Altap Salamander SDK which contains a binary executable that emulates the way the application interface to its plugins — acting as a “server”, so to speak.

Basically, the PMNG test unit could be a debugging tool exposing all the functions/interfaces to connect to plugins (both DDE and file I/O), providing a user interface with buttons to simulate various operations:

  • Load image/animation.
  • Import palette.
  • Save image/animation.
  • etc.

The test unit should contain some hard coded sample images (or procedurally generate them) to test exporting various type of images and animation (with/without alpha transparency), as well a quick previer for images loaded/imported via the plugins being tested. Basically, it would be a small scale PMNG emulator.

Developers could just drop plugins in the test unit folder for quick testing, with the test unit showing information about the data being passed to-and-from the emulated PMNG and the various plugins.

This would be very helpful to catch errors, simulate problems, and quickly preview how I/O is effectively working. The test unit should also act as a DDE server to test manipulation plugins.

Right now, testing plugins requires continuosly launching/shutting down PM, and there is no feedback mechanism except crash reports and successfully visualizing a loaded image. A test unit could expose internal data, provide validation functionality, etc.

Being PMNG priopietary, you’re the only one who could create such a test unit, by partially reusing some of PMNG internal functions (which would allow keeping the SDK always up to date with the latest PM version). Of course, the test unit would be distributed only in binary form (closed source).

It could start out as a very simple tool, and grow in functionality in the course of time. The SDK might stimulate and help third party development, and depending on the actual feedback from the userbase you could decide if it’s worth investing energy on or not.

What do you think?

1 Like

I fully understand and it makes sense. I’ll try to catch up with this soon. We already discussed some smaller changes and enhancements for the file i/o plugin, so I hope that I can create such a tool when addressing these.