ArgusMagnus
-
Posts
69 -
Joined
-
Last visited
Posts posted by ArgusMagnus
-
-
On 9/9/2018 at 8:37 PM, BoltBait said:
I have always been a fan of shorter UI's and in this pack I take advantage of some new functionality in Paint.NET v4.1 that allows for a more compressed look.
How can we (plugin authors) do this?
-
-
-
-
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).
-
2
-
-
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:
-
That's still a circumstantial hack.
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
[...] circumstantial and liable to break; and/or, it would tie my hands on future changes, improvements, refactorings. [...]
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).
-
You never know, if your external utility is good enough, it might eventually become an internal utility.
Happened with...uh...something. Something of BoltBait's, I think. Maybe Gaussian Blur +?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.
-
Oh yeah, pretty sure using goto's would compile quicker due less replacement coding in compilation. That's
pretty significant.
My guess is that the speed up is pretty unsignificant. This might become more significant the larger the project, but it also becomes more important to write well organized code.
-
Yeah, I know, but nontheless those plugins I listed (including CodeLab) are located in the UI somewhere, where they don't naturally belong and are there simply due to the lack of alternatives.CodeLab is located in the Effects > Advanced menu.
Maybe... I don't like it, because it means to have another little program only serving one small purpose which is not used very often having lying around somewhere. Perhaps I would still do it, but certainly not right away (I probably won't have time in the near future). But I would clearly prefer the Effects->Advanced->Plugin Installer option. I really think this would be more user-friendly. I could even rename it to PluginLab or something to make it fit better xDIt would still be quite useful as an external utility. Troubleshooting here on the forum would be easier, "go download this: (link) and use it"
Edit: On second thought, with an external utility, I could get the file extension association functionallity back which died with the FileType plugin. I would still want the Effect plugin for two reasons: 1. To keep the ability to preview effects before installing and 2. to have a way to access the plugin installer from within paint.net. This mainly because I don't like shortcuts to little tools I rarely use clustering my desktop/start screen and remembering names so I can search them is also not my forté. Within the application which it is used for is the place I would want it to be.
-
You are right, the location (File->Open) doesn't really make sense. I would argue that this is also the case for tools effect plugins like CodeLab, Plugin Browser, Color Harmonies or Effect Plugins which let you upload images to imgur or similar sites and that it at least is also not too far off (it still opens/loads something). But if you don't want that, I accept that.
You haven't mentioned how you feel about the Effect Plugin with the same functionality at all, would that be possible?
I'll be honest, I'm not motivated to realize this as an external utility, it you don't want it as plugin in any way, I will probably just drop this. The reason is that I can't see such an utility being used by a larger user base. I would not download/install/use an utility, which is not somehow accessible through the paint.net UI and I guess others probably wouldn't either.
-
Do you mind if I ask why? (I will respect your final decision, but let me try to convince you)
I could relative easily covert this to an external utility but I think this would greatly reduce the user experience and I don't know if this would be worth the trouble. Furthermore, in contrast to the plugin solution, it would require "hacks"/ugly methods (somehow get the paint.net process, read registry keys, etc.) which are more likely to fail/be broken by a future update of paint.net.
-
Hehe, as I said, not hard to crash^^
I've fixed this, because it required almost no changes.
Also the assembly version is now displayed.
I have a lot of ideas for improvement, e.g. highlighting conflicting assemblies (possibly with different colors: newer<->green, older<->red), detecting conflicts not only due to conflicting file names but also due to duplicate menu entries, providing an installer for the plugin, possibly with file extension association (so *.pdnplgn would automatically be opened by paint.net, this idea is actually the reason the FileType plugin version exists), but these things would require some work and thus time which I am not willing to invest before I know if I may release this on the forum.
-
I have developed a plugin installer. I know that this has been done before, but I wasn't happy with the existing solutions. I know that a plugin installer/management system is on Rick's ToDo list, but I wish to provide an intermediate solution, until the real one arrives.
The installer can be invoked in two ways:
1. FileType: Open->Plugin Installer (*.pdnplgn, *.zip)
2. Effect: Effects->Advanced->Plugin Installer
This will let you open a zip archive (optionally renamed to have a .pdnplgn extension). It will read the containing .net assemblies and show the contained filetype and effect plugins. It will also show you what already existing plugins will be overwritten. If it was started from the effects menu, it will also allow you to preview effects (double click on the effect) before installing it. After clicking "Install" the plugins launch a seperate process which then waits until paint.net is closed by the user and after that copies the files to the paint.net directory. When the installation is complete, it will give you the option to start paint.net up again.
However, this won't just simply copy dll's, it will check if there are assemblies which are referenced by the selected ones and copy them as well. If existing, it will also read the PluginInstallerInstructions.xml file in the archive (see the example "ArgusPaintNet (Text).pdnplgn") which lets plugin authors specify non-.net references (like native assemblies or any other filetype) which should be copied and also files which should be removed (e.g. if you have renamed your effect assembly and want the installer to remove the old one).
I have read the rules over and over again and I don't think this violates any of them (perhaps the "side effect" clause on FileType plugins, but I could easily remove that) but I'm still not sure if this will be allowed. I have read an old thread where something similar was removed/banned, but I don't know what was actually done since the code was removed.
I contacted Rick and he said, that this functionality won't work out as a plugin, but would probably be okay as an external utility, and said, I should post this to the developer section and see how this goes from there.
So.. I fear that what I have done till now won't be allowed, but I have still a little hope left since technically, the plugin only shows you plugins (similar to other plugins like the pinned Plugin Browser), the actual installation/file manipulation is done by an external program (you don't see this exe since it is included as resource in the plugin assembly and extracted to the temp folder when needed).
Since this might never make it to the public release section, I haven't put too much effort into it yet. It worked well on my personal computers with BoltBait's Plugin Pack and my own (included as ArgusPaintNet (test).pdnplgn), but it is not well tested. You probably wouldn't have a hard time to make it crash (e.g. by feeding it a corrupt archive).
I posted this here, so you can tell me if
1. what part of this idea you like and which part you don't
2. Rick (and perhaps senior members/admins) can tell me if this is allowed, and if possible, which part is not allowed (and optionally, just for my own curiosity, why it is not allowed)
3. If this gets the go ahead, you can help me test this, since something like this should be heavily tested before releasing.
Download:
https://onedrive.live.com/?id=429F16CCEF18E484%21351194&cid=429F16CCEF18E484&group=0
If you want to build this from the source, you will need VS 2015 (previous version probably won't compile it, since the source makes use of new C# 6.0 features).
I'm looking forward to your feedback
-
1
-
-
Would "Edge Detect+" be a better name? According to the plugin index it is not taken yet.
Does anyone use the "Corner" mode? (This plugin originally started out as a corner detection plugin, but as I kept going and tested the plugin, I began to see, that edge detection yields much more interesting results than corner detection and the math is almost identical, so switching between the two modes requires very little code changes). If not, I might remove the option altogether and instead add an option to perform the algorithm and different versions of the image. Currently the algorithm is performed on a grayscale image, but it could just as easily be run on individual channels
-
I can't really follow you. How would implementing wait loops with gotos instead of for-next have have resulted in processor speed independent waiting?
Nowadays, no one would implement waiting with loops, but usually there are better options than implementing this yourself with DateTime.Now, etc. such as Thread.Sleep or Timers (such as System.Timers.Timer)
-
This was exactly what I was looking for, thanks
-
I know I read the solution somewhere some time ago but I can't remember where..
What is the recommended way to execute a method on the UI Thread, e.g. for showing a MessageBox?
Im currently going with
Process process = Process.GetCurrentProcess(); Form form = Form.FromHandle(process.MainWindowHandle) as Form; form?.Invoke(new Action(() => { MessageBox.Show("Some Message"); }));But this seems a bit ugly..
Happened with...uh...something. Something of BoltBait's, I think. Maybe Gaussian Blur +?
Edge Detect+
in Plugins - Publishing ONLY!
Posted
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