Rules for plugins that are published on this forum

[midora]

Is it OK to add metadata to the document in the OnSaveT method of a filetype plugin?

Reason: Some (few) documents provide an ICC Profile (Exif 0x8773). I like to offer the possibility to use the document profile or to embed an external one during save. In this case I would like to rember the profile in the document.

[Rick Brewster]

Don't modify the input in OnSave(). (note to self: make the Document read-only for the duration of OnSave)

For the output, you can embed whatever you want for the file type that you're saving as. This doesn't require you to do anything Paint.NET-specific.

[ArgusMagnus]

I don't Need it right now, I found a better Workaround, but just out of curiosity:

 

Would it be alright to use a reflection "hack" to Change something in my own effects IndirectUI? (e.g. Setting a Checkbox to false when the Dialog is shown Independent of the last token)

[Rick Brewster]

Reflection = no. I will remove your plugin from the forum.

 

However, as usual, if you're just doing something for yourself (e.g. not publishing it on this forum) then you can do whatever you want.

[Rick Brewster]

New rule added to clarify this. see also: http://forums.getpaint.net/index.php?/topic/107032-tile/#entry511100

 

 

Plugins must not use reflection to reach into Paint.NET's internals.

If something is private or internal, then it's off-limits. Do not use reflection to reach in to get access. This includes instantiating classes, accessing private fields, etc.

[Rick Brewster]

Add two new rules, based on some terrible things I'm finding while wrestling to get plugins working with 4.3 by any means necessary

• Plugins may not require adding any files to the main application directory
• Plugins must not hook global events for Assembly loading, e.g. AppDomain.AssemblyResolve

[Rick Brewster]

Added two more, pertinent to the 4.3 + .NET 5 release:

• Plugins with dependencies (shared DLLs) must have a .deps.json and go into their own directory
• Plugins should not use C++/CLI

[Rick Brewster]

Added one more

• Plugins may not require installing/using an older version of Paint.NET

[otuncelli]

Is obfuscation allowed?

[Rick Brewster]

I don't see why you'd need to, but there's no rule against it and no reason PDN would have to care.

[Rick Brewster]

Added another rules that has come about while I've been wrestling to get legacy plugins to work with 4.3

• Plugins must not do discovery and loading of other plugins

(there is a much better alternative now to doing it yourself)

[Rick Brewster]

Added another rule that I should've added a week or two ago with the release of PDN 4.3,

 

Plugins that use shared libraries must be packaged and installed correctly

[VcSaJen]

Does the plugin need to support all architectures (x86_32, x86_64, ARM64), or x86_64 is enough? I know that 4.4 will drop support for x86_32, but that still leaves 2 architectures.

[Rick Brewster]

I don't think it's reasonable to require specific/all architecture support, especially since most people don't have an ARM64 system to do any testing on.

 

If you don't support all architectures, please call it out somewhere in your plugin's description such as in the release notes, version history, system requirements, or near the download link.

 

I encourage you to publish the ARM64 DLL, if you can build it that is, even if you can't test it yet. You can mention that it's untested. If someone tests it and reports that it works well for them, you can of course remove that note. If they report that it's broken, then you can either remove the support for ARM64 in your next update, or of course you can figure out how to get it working and release a fixed update. ARM64 on Windows is very nascent, so people using ARM64 have to be willing to accept "beta" levels of support at this time, including the responsibility to report if something doesn't work. But, without the availability of ARM64 software in the first place -- even if untested / "beta" -- it can never take off. Chicken vs. egg, in other words.

 

Consider another example: What if someone wants to publish a plugin that only supports ARM64? I think this would be rare, and kinda strange :), but as long as this is clearly spelled out then I see no reason to prohibit it. Or, what if someone wants to publish a plugin that requires Windows 11, or an NVIDIA GPU? That's fine, as long as it's called out in the plugin description/notes.

 

If your plugin does not support a certain architecture or OS (or whatever), it's a very good idea to detect this in your Effect, FileType, or IFileTypeFactory2 constructor and to throw a PlatformNotSupportedException. You can do this by checking the value of System.Runtime.InteropServices.ProcessArchitecture for CPU, and Environment.OSVersion for OS version. The alternative to doing this is that your plugin will probably just crash when someone tries to use it, which could take down the process and cause data loss, which would then mean I'd have to block the plugin and mark it as unstable.

 

Once 5.0 ships, it won't be allowed to ship a plugin that does not work on 5.0. This doesn't mean it must require PDN 5.0. You could build the plugin to work on 4.2.16, for instance. However, it will be more difficult to do this because of changes in Paint.NET and in .NET itself, so I wouldn't recommend it. In this scenario you'd have to build and test on <=4.2.16 (.NET 4.x), and 4.3 - 4.3.2 (.NET 5), and 4.3.3 - 4.3.12 (.NET 6) and >=5.0 (.NET 7). Much simpler to just target PDN 5.0 and .NET 7. (Edited to change 4.4 to 5.0)