While working on a file I/O plugin which exports to a new image format, I realized that if I omit from the DLL the file-import related functions PMNG complains at startup that the plugin is invalid.
E.g. I tried to omit functions like getWidth(), getHeight(), canExtractPalette(), etc., which are only used by plugins that support importing images into PM — whereas my plugin only exports — but if I do so I get the above mentioned error and my plugin stops working.
Does PM NG check during initialization that a plugin DLL contains all of the plugin function, regardless of whether it supports only certain features?
It would make more sense to exonerate programmers from having to add dummy DLL functions (that effectively do nothing) just to comply with the full list of supported functions. Since during startup PM queries each plugin about the supported features (via isReadSupported(), isWriteSupported(), etc.) it should be able to limit the DLL functions checks to those which are required based on the declared features set supported by the plugin.
@jan.cosmigo, I was thinking that since the above changes would make a file i/o plugin unusable with older version of PM (i.e. v6 or below, which use a strict interface v1) it might worth adding these changes when the file i/o interface is updated to v2 — i.e. when some other improvements are implemented, which also break backward compatibility with versions that don’t support interface v2.
Of course, here I’m assuming that PM NG will always support both newer and older interfaces to preserve backward compatibility with existing plugins.
Here are some further thoughts on possible improvements…
New DLL Func to Allow User Dialog
While creating my latest plug-in, to export to SVG:
I’ve noticed the lack of a dedicated DLL call to allow the plugin to present end users with an options dialog.
Ultimately, I’ve retorted to adding my custom dialog inside the initialize() call, but this has some disadvantages.
First of all, if the plugin supports exporting multi-frame animations, the dialog would pop-up with each frame, unless some special variables are created to track if the dialog was already shown within the current task.
During the initialize() call, PM NG doesn’t prevent closing the current project, so if the user does close the project while the dialog is waiting for confirmation it will cause a crash when the dialog exits. PM should be frozen while the special DLL call for the plugin settings dialog is open.
Basically, it would be nice to have a new function that allow the plugin to optionally present users with some graphic interface to set some custom options. This procedure shouldn’t really exchange any data between PM Ng and the plugin, for its sole purpose is to allow a once-per-task options dialog. It might be worth, however, to contemplate a return value in case the user decided to abort the operation from within the dialog (e.g. this function might set error).
Currently, there are various DLL functions which can set error and abort the current operation, but the interface lacks a means to allow the user to abort the operation without raising a proper error — surely, the plugin could set error and provide a string like "User aborted operation" as an error description, but having a way to distinguish between real plug-in errors and user abortion would be good, for the former indicates that something went wrong with the plugin (file operations, memory, data, etc.), whereas the latter indicates a spontaneous task interruption.