Support for Plugins Admin & NppPluginList

ianwilliams1

After TextFX disappeared following NPP upgrade, I found this post, which noted there’s now a TextFX2 (which works for me!).

Wondering if someone might update the Plugins List to show the original is no longer compatible and add an entry for the TextFX2 and link to repo, etc. ?

Is that the responsibly of the plugin developer to add and what about the deprecation ?

I’d submit a PR, but have no idea what the appropriate notations would be.

ianwilliams1

Also, how does TextFX2 get onto the Plugins Admin list of plugins? Is there something @rainman74 needs to do?

PeterJones

@ianwilliams1 said in Support for Plugins Admin & NppPluginList:

Also, how does TextFX2 get onto the Plugins Admin list of plugins? Is there something @rainman74 needs to do?

Yes. it is up to the author/maintainer of a plugin to decide whether or not to add it to Plugins Admin.

Roberto Iseppi

The plugin:
“Customize Toolbar” 5.3
is causing NPP 8.4.8 to not display the menu icons.
R

Alan Kilborn

@Roberto-Iseppi said in Support for Plugins Admin & NppPluginList:

is causing NPP 8.4.8 to not display the menu icons.

Can you be more specific as to what “menu icons” you are talking about?

ensnared

Apologies if this isn’t the place to report obsolete plugins in the list. If it isn’t, please direct me to the proper place :)

The plugin NppQrCode (v0.0.0.1) can not be installed (on x64 atleast). It gives the following error:

Also, the homepage URL in the description for the plugin is dead (I’m not allowed to post actual links, but it’s
github(dot)com/vladk1973/NppQrCode)

rdipardo

A new version (0.0.0.2) has been available since Notepad++ 8.5.8:

If you’re stuck with 8.5.7 or something older, you can also get it directly from GitHub.

Coises

In the online manual (which the GitHub nppPluginList repository also references), there is a section about testing updates to the Plugin List:

Test your plugins locally

That section gives links to x86 and x64 debug copies of Notepad++ version 7.8.1. The WinGup versions are 5.1.1 (current is 5.2.9). When I put them in a copy of a current (8.6.8) portable folder and try to launch, they ask if I want to download an update and when I say no, nothing launches at all.

I know I tested when I first added Columns++ to the plugins list; I think I gave up on the documented procedure and instead compiled a version of Notepad++ that I modified somehow to make it use the xml plugins list instead of the dll. So, whatever I did, it wasn’t the “right” way to do it, and I no longer remember exactly what I did.

Since then I’ve just made changes, pasted the new hashes and assumed I didn’t make any mistakes, but I thought I’d test my last update this time to be sure, and… here I am, looking a documented test procedure that doesn’t work.

The point of all this being: can the manual be updated to reflect the actual, current recommended procedure for testing, whatever that is?

(My impression was that the GitHub actions on pull requests for nppPluginList only test whether the XML is valid, not whether the new plugin’s URL is accessible and whether the content passes the hash check. Is that correct?)

PeterJones

@Coises ,

Ideally, @donho should be updating the files at those four static URLs every time there’s a new release, because otherwise, with every release, the UserManual would have to edit those links to the new location for the debug builds.

Alternately, the User Manual could be modified to explain the procedure to find the newest debug builds of N++ and WinGup. Unfortunately, the “debug” builds don’t get put in https://github.com/notepad-plus-plus/notepad-plus-plus/releases/latest – if they did, that would be the easy. And the Npp/WinGup releases don’t include any built files… and I don’t know if the gup4win/wingup releases (which do have the zip) are compatible with N++ plugin testing or not.

As a procedure for finding debug builds, I think this will work:

Go to https://github.com/notepad-plus-plus/notepad-plus-plus/releases/latest
Click on the commit that goes with that release (the 7-hex-digit)
- Example:
Click on the Green Checkmark on the Commit message, which will show a dropdown window
Scroll down to the appropriate “debug” build and click Details for Win32 (32-bit), x64 (64-bit), or ARM64 (for 64-bit ARM processors)
- It’s actually not important which of the Details you click on – because the Summary link in the next step takes you to the same page for all the builds in this dropdown
On the Details page, click on the Summary
If it hasn’t been too long and GitHub hasn’t cleaned up the artifacts, then you can scroll to the bottom of the Summary page, and find the right Debug build for Win32, x64, or ARM64 entry in the Artifacts list and download that Artifact:
- Notepad++.MSVC.Win32.Debug
- Notepad++.MSVC.x64.Debug
- Notepad++.MSVC.ARM64.Debug
That downloaded Artifact is, I believe, the most recent equivalent of the N++ links in the User Manual.

Let me know if that procedure, ~~combined with grabbing the gup4win/wingup release~~, is able to work for debugging. If not, then @donho or someone more familiar with the plugin-testing procedure will need to chime in.

update: given how old the gup4win/wingup is, that’s probably not a good idea. Since the UM link to the assets hierarchy for wingup.release.x64.zip calls it the release rather than debug, I am wondering if it’s safe to just use the gup.exe distributed with N++ v8.6.8 when using the v8.6.8-debug notepad++.exe – I’d recommend that as your first experiment.

Coises

@PeterJones said in Support for Plugins Admin & NppPluginList:

Let me know if that procedure […] is able to work for debugging.

Yes, it works. Thank you.

I didn’t bother to examine the code to find out how it works, but apparently using a debug version of Notepad++ automatically uses the .json plugin list instead of the .dll, so the test proceeds just fine. Just to be sure, I tried changing my plugin’s hash value in the list and it flagged the mismatch, so it is validating the hash.

I don’t think that’s an unreasonably difficult procedure for plugin authors to follow (relative to the work to actually write and debug a plugin!). It’s not a big deal if updating those fixed-URL debug builds is inconvenient. It would just be good to have the procedure documented, either in the manual or in the plugin list readme (to which the manual could refer — personally, I think it makes more sense in the plug list readme).