Jump to content


  • Posts

  • Joined

  • Last visited

About alexo

  • Birthday 01/01/1970

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

alexo's Achievements


Enthusiast (6/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges



  1. That is correct of course, and it's the reason I said "may have" above. It could serve as a flag to look at the post, since the process is manual. A diff from the previous version would make it easier to distinguish between an actual update and fix. Still not a good solution but it could work. A better approach would be to look for a distinctive pattern within the message body (Such as "~~version=" for example) and let plugin authors know that if they include it and keep it updated, an automated system could track the versioning. The ones that want to take advantage of the feature will do it.
  2. Thank you for the explanation, EER. I'm just going to brainstorm a little... I assume (and please correct me if I am wrong) that the plugin uses the data from the plugin index, which tracks the posts in the forum, either automatically or manually. The most effective way of doing it IMHO would be to scrape the data directly from the DB. Even if some manual massaging would be needed, it would still be a good starting point. I do not have access to the Invision DB schema so I cannot say whether it tracks the modification time of edited posts, but I know that most (all?) other BBS systems do, and if that information is available, then it could indicate that a new version may have become available. Just a thought.
  3. I don't know if I have the time and knowledge to work on it. If the index does not contain the upload timestamp and/or file hash then obviously it is going to be difficult to do something like this.
  4. I don't know what the index contains, or where it comes form. I did not see that information in the thread.
  5. Doesn't the plugin download an index? It must come from somewhere.
  6. Since the Plugin Browser has knowledge of both the plugins installed on the users system and the available plugins, it would be nice to show which plugins are out out of date. The Notepad++ Plugin Admin and the Cygwin installer have this functionality.
  7. I've been playing with it a little lately in both PDN and Gimp and noticed that the Gimp plugin usually gives me better results and is also significantly faster, especially on large images. Given that it is basically the same algorithm, I wonder what may cause it.
  8. Immediate crash when clicking on the "Image" dropdown menu. Crash log attached. Reverted to 4.0.21 pdncrash.4.log
  9. Getting errors when using lasso selected regions: File: C:\Program Files\paint.net\Effects\ContentAwareFill.dll Name: ContentAwareFill.ContentAwareFillEffect Version: Author: null54 Copyright: Copyright © 2018 Nicholas Hayes (aka null54) Website: https://forums.getpaint.net/index.php?showtopic=112730 Full error message: PaintDotNet.WorkerThreadException: Worker thread threw an exception ---> System.NullReferenceException: Object reference not set to an instance of an object. at ContentAwareFill.ContentAwareFillEffect.OnConfigDialogProgress(Int32 value) at ContentAwareFill.Resynthesizer.Synthesize(Int32 pass, Func`1 abortCallback) at ContentAwareFill.Resynthesizer.ContentAwareFill(Func`1 abortCallback) at ContentAwareFill.ContentAwareFillEffect.OnSetRenderInfo(EffectConfigToken parameters, RenderArgs dstArgs, RenderArgs srcArgs) at PaintDotNet.Effects.BackgroundEffectRenderer.ThreadFunction() in D:\src\pdn\src\PaintDotNet\Effects\BackgroundEffectRenderer.cs:line 225 --- End of inner exception stack trace --- at PaintDotNet.Effects.BackgroundEffectRenderer.DrainExceptions() in D:\src\pdn\src\PaintDotNet\Effects\BackgroundEffectRenderer.cs:line 418 at PaintDotNet.Effects.BackgroundEffectRenderer.Abort() in D:\src\pdn\src\PaintDotNet\Effects\BackgroundEffectRenderer.cs:line 374 at PaintDotNet.Effects.BackgroundEffectRenderer.Start() in D:\src\pdn\src\PaintDotNet\Effects\BackgroundEffectRenderer.cs:line 320 at PaintDotNet.Menus.EffectMenuBase.<>c__DisplayClass42_5.<RunEffectImpl>b__5() in D:\src\pdn\src\PaintDotNet\Menus\EffectMenuBase.cs:line 1032
  10. The problem is that if I want to move the slider from the default 50 to say 12, the process starts as soon as I start moving the slider, before it reaches the mark. Then I have to wait for it to finish (can take 20 second's or so), then try to trigger it again, which is problem when the slider is already in the correct position, so I end up running it twice more. It is an unnecessary inconvenience.
  11. A problem that iy have with this plugin is that it immediately starts working when I change the settings, even if I am not done changing them, and then I have to wait a long time for it to finish only to update the settings again. It would be better to have an "apply" button.
  12. Which ironically does not work with selections.
  13. I agree with MJW on this one. The plugin requires a selection, and I don't see much of a difference between it's positioning and the "feather selection" one. My vote is for selection.
  14. Thank you null54, I've been waiting for a long time for something like this!
  • Create New...