alexo

I think that it makes sense to offload some of this work to the plugin writers and automate the rest. For example, when publishing a plugin, its author will fill in a short template with the plugin name, version number, release date of the version, etc. and will update it in It can be either in the first post of the corresponding thread, or externally, and can be scrapped on a schedule. I am basing this suggestion on Notepad++. It has a built-in plugin manager that shows which plugins are available, installed, updated, and incompatible:

All good! By the way, is there a way to quickly check all installed plugins for updates?

Does the "release" date for a plugin specify the initial release, the latest release, or something else?

Attached: screenshots + reports of plugins Yes, I now realize that BoltBait's plugins need updating, but I believe there are others. temp.zip

Is it possible to install the 5.0 beta and 4.x side by side?

Is it possible to to have a plugin compatibility feature for 5.x that will allow older plugins to work with it? I was surprised when I installed the alpha that many of the plugins I have did not show at all, and the one that I use the most (Content Aware Fill) crashed on invocation. Some of the plugins are not longer maintained but are still useful, and it will be a shame if they are rendered inoperative by the upgrade.

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=1.2.3.4~~" 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.

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.

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.

I don't know what the index contains, or where it comes form. I did not see that information in the thread.

Doesn't the plugin download an index? It must come from somewhere.

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.

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.

Thanks, that fixed it.

Immediate crash when clicking on the "Image" dropdown menu. Crash log attached. Reverted to 4.0.21 pdncrash.4.log