I've noticed that windows created by file i/o plug-in tend to partially inheriting PMNG's skin (e.g. the dark/light theme) while partially adopting the Win 10 look-&-feel of modern windows.

I should try to disable the "Use modern XP themes" option in the PBCompiler, and see if this allow custom windows to fully inherit PMNG's skins.

• Test compiling a sample plug-in without "modern XP themes" option.
• Find out which skin library PMNG is using, and whether its documentation provides useful info.

Currently, whenever an image containing an Alpha layer is exported, the plugin is invoked twice (for image.ext and image.alpha.ext). This occurs regardless of whether isWriteTrueColorSupported() returns true or false.

This seems connected to PM NG native behaviour when saving to file formats that don't support alpha channels, for which PM created and additional .alpha.<ext> file to store the Alpha layer in order to reconstruct it when loading that image again.

This is either a bug or an undocumented feature — the former suggests that PM should be handling creation of the extra file.

For more details, see also:

• Cosmigo Forum » File I/O: Exporting image with Alpha layer creates two files
• cosmigo/pmotion-assets#7

• Try to understand how this bug affects the current interface.
  • Annotate the problem in the boilerplate sources.
• Track PMNG updates for when it's fixed.

I need a clarification about the plugin function getImageCount().

This function is documented as being able to return error, but it's the only function of those that can set error that is also expected to return a value (i.e. the number of frames).

I'm assuming that in case of error the function is also to return false (0), and that it's not enough to just set the error. I'm assuming that, since at least 1 image is expected by PM, a return value of 0 would be considered an error.

If this is the case, it should be mentioned in the Procedure comments.

Se also:

• cosmigo/pmotion-assets#7

When Travis CI is correctly setup and working, and the build status badge is green again (See cosmigo/pmotion2svg#1):

• Check that there are no more links/URLs pointing to the old repository.
• Fix any links pointing to old GH Pages website URL of the pmotion-assets repository.
• Close the Cosmigo Transferal milestone.

References

• GitHub Docs » Transferring a repository

Missing info on DLL functions.

I need to understand if DLL functions specifically targeting import or export functionality can be left out entirely in those plug-ins that won't use them — i.e. if these functions still require defining DLLProcedures that do nothing, or if they can simply be omitted since PM wouldn't try to call them after having acknowledged the plug-in supported features via the registration functions.

For example, an import plug-in shouldn’t expect any calls to beginWrite() or
writeNextImage(), and an export plug-in shouldn’t expect any calls to getTransparentColor() or isAlphaEnabled().

For more info, see also:

• Cosmigo Forum » HELP: More File I/O Interface Clarifications
• cosmigo/pmotion-assets#6

Fix a typo in PoC/file-io/fake/FakePlugin.pb:

logger::Settings\WinTitle = "FAKE Puglin v" + #PLUGIN_VER$

... the window title should be "FAKE Plugin", not "FAKE Puglin".

Ownership of this repository was transfered to the newly created @cosmigo organization:

• https://github.com/tajmone/pmotion-purebasic (previous location)
• https://github.com/cosmigo/pmotion-purebasic (current location)

Replace all references to the old repository URL, form the @tajmone user account to the @cosmigo organization in:

• Repo settings comments.
• Markdown files.
  • Travis CI link
• PureBasic sources.

TRAVIS CI NOTE — Travis CI validation will not work until @cosmigo enables Travis on the repository (See cosmigo/pmotion2svg#1). Since the badge is already broken on master branch, there's no need to wait for Travis enabling before merging these fixes.

PB CODE NOTE — I probably shouldn't change the version info in the PB sources after fixing the URLs. These are minor changes, mostly to comment lines, so they shouldn't affect their version number. Furthermore, it's all in Alpha stage, and there are no tagged releases at the moment.

References

• GitHub Docs » Transferring a repository

Missing info on DLL functions.

Is the canExtractPalette() a generic DLL function gathering info about the plug-in supported features (e.g. like isReadSupported()) or does it apply to the specific files being processed? In other words, is it a plug-in registration function or is called on a per-file basis?

For more info, see also:

• Cosmigo Forum » HELP: More File I/O Interface Clarifications
• cosmigo/pmotion-assets#5

In the PureBasic File I/O plug-in template progressCallback() needs to be defined in the main body, and then Shared inside setProgressCallback() (either that or just define it as Global), otherwise it won't be available to other procedures.

Also, the following line need to be fixed:

progressCallback.ProtoProgressCallback = @*progressCallback

it should be = *progressCallback!

• Fix template code accordingly.
• Add useful comments on how to handle it.

Missing info on DDE plugins.

In his Pro Motion DDE Interface in C, Thiadmer Riemersma brings up the issue of wether asynchronous execution of DDE plugins is mandatory or not:

My implementation of a DDE “execute” is asynchronous. I do not know whether Pro Motion requires this. A few other applications for which I implemented DDE conversations required asynchronous execution, so I left it that way. Note that the Delphi implementation also does an asynchronous execution.

• Q: Can DDE plugins be interfaced synchronously too?

For more info, see also:

• cosmigo/pmotion-assets#2