ArgusMagnus

Thanks for the feedback. 1. Thats actually a left-over I missed, which has no effect as of now 2. I plan on also re-releasing the convolution plugin, so sit tight

How can we (plugin authors) do this?

Updated, see https://forums.getpaint.net/topic/32337-argusmagnus-plugin-pack-20181019/

Updated, see https://forums.getpaint.net/topic/32337-argusmagnus-plugin-pack-20181019/

Updated, see https://forums.getpaint.net/topic/32337-argusmagnus-plugin-pack-20181019/

I've updated my plugins to be a) v4.1.* compatible and b) completely self-contained (one dll file, no dependencies). The plugin behavior is unaltered. When updating, remove all Argus*.dll files first. Also, there is one new effect (Barcode renderer) and one new filetype (app icon set).

ah.. I feel stupid.. Thanks for the quick Responses!

Is there a Basic documentation/how to for writing FileType plugins? I've tried with the help of examples found online and based on the source of plugins like TinyPNG, but I cannot get PDN to Show me my plugin when I click "Save as...". This is what I have so far, any help would be appreciated. (It's a save-only plugin): public sealed class TestFileType : FileType, IFileTypeFactory { TestFileType() : base("Test", FileTypeFlags.SupportsSaving | FileTypeFlags.SavesWithProgress, new[] { ".test" }) { } protected override Document OnLoad(Stream input) { return null; } protected override void OnSave(Document input, Stream output, SaveConfigToken token, Surface surface, ProgressEventHandler callback) { // Do save operation... base.OnSave(input, output, token, surface, callback); } FileType[] IFileTypeFactory.GetFileTypeInstances() { return new[] { new TestFileType() }; } }

It would certainly be worth it. The plugin in the developer section I linked to is fully functional (at least it was at the time) and does exactly that (by lauchning a separate process which requests elevated access to install). In fact, the installation process (copying files, restarting Paint.net) is fairly simple, the hard part is to correctly resolve dependencies and conflicts.

Unfortunately, the feature you are requesting (and rightly so in my opinion) is forbidden to be included in a PlugIn:

I fail to see why. Of course, "hack" is not really a well defined term, your definition obviously differs from mine. But given the fact that you already can't remove/refactor the EffectTokenConfigDialog class without braking a lot of plugins and you probably won't move away from windows form either, this doesn't seem to be "liable to break" to me. I don't mean to offend you and I appreciate the time you are investing into this amazing free software, but, as you said yourself, these things can take quite some time. This is understandable, but if we (plugin authors) then are forbidden to use real short-term solutions, simply because you don't seem to like them, this is very frustrating. (e.g. I'm still disappointed that my Plugin Installer Plugin was rejected. I've read posts from you from 2008 or so saying that you are planning to provide a plugin management system, which hasn't happened yet and yet, I am not allowed to provide an intermediate solution for unkown reasosn)

If you still need to do something similar without relying on Form.ActiveForm maybe you could iterate over Application.OpenForms and check if one derives from the EffectConfigTokenDialog class to get the effect dialog form. This probably won't be I did something similar to check whether an effect was truly cancelled or if the IsCancelled flag was just set because the user changed values (to determine if I could discard cached data for good).

There are cases however, where you can't get around external dll's (e.g. when you need to interop with native dlls). In my opinion, the real problem is, that the user needs to manually copy installation files/dlls. Ideally, we would provide our plugins with installers, which prevent the user from overwritting dlls with outdated versions (of course you still have to take care, that newer versions are backwards compatible).

Ok. I have read the quoted statement, the reason why it wasn't clear to me if this included the effect plugin is, that your whole explanation why this shouldn't be done as a plugin was based on the assumption, that it would be a filetype plugin. It may be a good idea to update the rules to include this (till the end it remains unclear to me, why this shouldn't be done as an effect plugin, a corresponding entry in the rules could help prevent such confusion in the future).

I don't think this is likely, other than a real effect which can probably very simply be integrated into the internal assemblies, Rick probably has his own ideas for a real plugin management system and won't just integrate an external tool, even if it is good. So.. I haven't really gotten an answer, can I keep the Effect Plugin? If yes, is anyone interested in helping me test it before I release it to the public? I might still do the external utility, but I don't have too much free time on my hands right now. Edit: I've uploaded a new version with some small fixes, it's less likely to crash now.