Jump to content

Rules for plugins that are published on this forum


Rick Brewster

Recommended Posts

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.

midoras signature.gif

Link to comment
Share on other sites

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.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

  • 3 years later...

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)

My batch Image Processor: https://imagenator.codeplex.com

Link to comment
Share on other sites

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.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

  • 5 months later...

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.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

  • 2 weeks later...

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)

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

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)

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...