New built-in Plugin Admin (Plugin Manager) is ready

donho

@donho stated here that this behaviour will be changed. Thus in the future the installation folder should be <Npp-installation folder>\plugins<plugin-name> again.

Not sure about the point you’re talking about. Could you elaborate it?

dinkumoil

@donho said:

@dinkumoil
Not sure about the point you’re talking about. Could you elaborate it?

In this comment I stated:

2.After plugin installation Notepad++ is not restarted. That seems to be nice at first glance but causes serious problems.

Your answer in this comment was:

The 2nd point you mentioned is a bug, will be fixed in the future.

I interpreted this in that sense that in the future after plugin installation Npp will be restarted again to avoid problems with plugins which need this behaviour. We have seen that sending a NPPM_READY message to plugins after installation is not sufficient because @chcg reported in this comment that NppFTP still isn’t initialized correctly:

@chcg said

For NppFTP the NPPN_READY doesn’t solve it completely. Now the docking and the message window are constructed/ visible, but the content is still not there. Maybe there is another difference to the start of n++ itself.

The thing @pnedev and I wanted to point out is that with a local installation (performed by installer exe) the plugins currently are not installed under C:\Program Files\Notepad++\plugins but under C:\Users\<user-name>\AppData\Local\Notepad++\plugins. This difference causes problems since it is only possible to query the installation folder of Npp but not the storage location of the plugin itself.

My current algorithm to get the storage location of my plugin DLL file and its documentation file is as follows (if this algorithm is wrong please point me to the correct method to do that):

Send NPPM_GETNPPDIRECTORY to Npp to query the installation folder of Npp.
Append plugins.
Append the plugin name.

This would result in e.g. C:\Program Files\Notepad++\plugins\AutoCodepage. But currently there is no folder of this path since the plugin gets installed under C:\Users\<user-name>\AppData\Local\Notepad++\plugins\AutoCodepage.

donho

@dinkumoil

The thing @pnedev and I wanted to point out is that with a local installation (performed by installer exe) the plugins currently are not installed under C:\Program Files\Notepad++\plugins but under C:\Users<user-name>\AppData\Local\Notepad++\plugins.

Damn! I miss again!
https://pbs.twimg.com/media/ChxfvQVVEAEQvXH.jpg

I interpreted this in that sense that in the future after plugin installation Npp will be restarted again to avoid problems with plugins which need this behaviour.

No, it’s not what I wanna do. I have added NPPN_READY, obviously it’s not enough, there is (are) other notification(s) missing we just need to add it (them).

dinkumoil

@donho said:

No, it’s not what I wanna do. I have added NPPN_READY, obviously it’s not enough, there is (are) other notification(s) missing we just need to add it (them).

Why do you want to make life difficult for you (and plugin developers which have to assist you to find the required notifications)? When plugins get updated or uninstalled a restart of Npp happens (currently) anyway.

Revert the installation path for portable and local Npp installations to the same location and restart Npp to perform actual plugin installation in admin mode - you (and we plugin authors) would be ready. That’s also KISS.

chcg

Some points from PluginManager feature requests:

https://github.com/bruderstein/nppPluginManager/issues/33
Feature Request: UDL repository -> update not just plugins, but also UDLs and maybe themes
https://github.com/bruderstein/nppPluginManager/issues/119
Disable Plugin updates -> meaning no automatic check for updates + specific right on user\plugin base
https://github.com/bruderstein/nppPluginManager/issues/133
Import/export installed plugins -> restore/sync current plugin constellation on a different computer/with a different user
https://github.com/bruderstein/nppPluginManager/issues/42
Find dead links -> Create a script to check if the provided list is still consistent and all plugins\links from the list still exist

pnedev

@donho ,

I second what @dinkumoil said:

The installation path for plugins should be $Notepad++_Install_folder\plugins mainly because of the portable version of Notepad++.

If you decide to keep the installation destination as it is now (C:\Users<user-name>\AppData\Local\Notepad++\plugins) then perhaps the user should be asked if the plugin is to be installed only for him/her or for anyone using the computer.

@dinkumoil ,

The Notepad++ restart upon plugin installation is not very elegant since this is just a DLL being plugged into the editor and all it needs to work properly is the right sequence of notifications. Now, I don’t address here the permissions problem to install the plugin in a place needing an elevated rights - I’m not quite aware of that issue at the moment.

If you need to get the real plugin DLL installation path here is what I do:

TCHAR gDllPath[MAX_PATH];

BOOL APIENTRY DllMain(HINSTANCE hModule, DWORD reasonForCall, LPVOID )
{
switch (reasonForCall)
{
case DLL_PROCESS_ATTACH:
::GetModuleFileName((HMODULE)hModule, gDllPath, MAX_PATH);

Don,

AFAIK, what a plugin needs to initialize properly is loading its main DLL (LoadLibrary() - this will also trigger DLL_PROCESS_ATTACH) then call getName() and getFuncsArray() and setInfo() and last send NPPN_READY notification. That should make it fully functional (unless I’m missing something).

In the case of updating a plugin, the plugin has to properly unregister itself with Notepad++ on DLL_PROCESS_DETACH so there are no conflicts in the consequent plugin reload.

donho

@pnedev

The installation path for plugins should be $Notepad++_Install_folder\plugins mainly because of the portable version of Notepad++.

If Notepad++ is not installed in “Program Files” and doLocalConf.xml is present, Plugins Admin will install plugins into “$Notepad++_Install_folder\plugins” - is it not the case for you?

Edit: I just checked in current official released packages, GUP.exe, which is needed by Plugins Admin, is not available in any zip packages (and it should not be, since GUP.exe will get installer EXE and execute it - that’s not the expected behaviour of portable version). I have no (yet) a perfect solution for it. So both GUP.exe and nppPluginList.dll will only be included in installer in the next release.

The Notepad++ restart upon plugin installation is not very elegant since this is just a DLL being plugged into the editor and all it needs to work properly is the right sequence of notifications.

I couldn’t agree more.

AFAIK, what a plugin needs to initialize properly is loading its main DLL (LoadLibrary() - this will also trigger DLL_PROCESS_ATTACH) then call getName() and getFuncsArray() and setInfo() and last send NPPN_READY notification. That should make it fully functional (unless I’m missing something).
In the case of updating a plugin, the plugin has to properly unregister itself with Notepad++ on DLL_PROCESS_DETACH so there are no conflicts in the consequent plugin reload.

Yes, that’s my point. The process to load a just installed plugin is the same as the one which is loaded from the startup of Notepad++.
Is there any other plugin doesn’t work after its installation by Plugins Admin?

dinkumoil

@pnedev
Thank you for your code snippet. I had this method not in mind because in Delphi the DLL entry function is hidden in the RTL. It is only possible to install a hook function with the following signature DllMain(DWORD reasonForCall). The DLL instance handle has to be obtained from a global variable called HInstance.

@pnedev said:

The Notepad++ restart upon plugin installation is not very elegant since this is just a DLL being plugged into the editor and all it needs to work properly is the right sequence of notifications.

what a plugin needs to initialize properly is loading its main DLL (LoadLibrary() - this will also trigger DLL_PROCESS_ATTACH) then call getName() and getFuncsArray() and setInfo() and last send NPPN_READY notification.

Yes, this should do the thing but NppFTP seems to be an example where this sequence isn’t sufficient. Maybe there are other plugins where it is the same (Wild guessing: There could be required some WM_XXX messages, in the worst case this may be plugin dependent).

My point is the following:

Plugin installation happens only one times, also uninstallation. In contrast updating a plugin happens more frequently.
Performing plugin updates restart-free is (as far as I know) a complicated thing, at all it makes no sense (see below).
If it is not possible to update plugins restart-free why there should be invested effort to make installations restart-free?

Why do I think restart-free plugin updates are complicated?

Plugins can manipulate the UI of Npp in various ways:

Inserting icons into the toolbar.
Inserting icons into menus (Menu Icons plugin).
Manipulating the whole toolbar (Customize Toolbar plugin).
Adding an entry to the Plugins menu including a submenu.
Adding other menu entries in arbitrary menus of Npp (ToolBucket plugin) or even adding a new menu in the menu bar (TextFX plugin).
Opening (docked) windows and modeless dialogs.
Inserting new windows in Npp’s UI (e.g. HEX editor’s address bar above the hex data).

All these manipulations have to be reverted when updating a plugin before Npp unloads its DLL and this case should be distinguishable from simply terminating Npp, thus it can’t be done in DllMain as a reaction to a DLL_PROCESS_DETACH call - there has to be a new Npp notification to inform plugins that they are about to be uninstalled (updating is a sequence of uninstall - install).

Furthermore, currently there is only a NPPM_ADDTOOLBARICON and no NPPM_REMOVETOOLBARICON (see 1.); there is only a method to add entries to the plugin’s submenu in the Plugins menu and no method to remove them (see 4.); the other points (2., 3., 5., 6. and 7.) are based solely on plugin code and require more or less effort to revert them.

Why do I think restart-free plugin updates make no sense?

There are two categories of plugins:

Stateless plugins
Stateful plugins

Stateless plugins perform simple actions, e.g. my AutoCodepage plugin (it monitors user actions and switches the document encoding scheme if neccessary) or @donho 's PorkToSausage (works only on-demand). These plugins are not critical for restart-free plugin updates.

Stateful plugins create a state by themself, e.g. NppFTP, @pnedev 's Compare plugin, scripting plugins with debugging capabilities (e.g. CS-Script) or the HEX editor plugin. These plugins are critical for restart-free plugin updates.

A state includes:

open windows (all plugins mentioned above)
open network connections (NppFTP)
set path for FTP session (NppFTP)
processing data and displaying results (Compare)
state of a debug session (CS-Script)
maybe more that I’m not aware of at the moment

To restore this state after a plugin update requires much effort, I guess that nobody wants to do that, maybe its even impossible. Thus restart-free updating makes no sense - after updating users would have to restore the desired state by themself, there would be no benefit compared to the current situation.

pnedev

@donho ,

If Notepad++ is not installed in “Program Files” and doLocalConf.xml is present, Plugins Admin will install plugins into “$Notepad++_Install_folder\plugins” - is it not the case for you?

I haven’t tried with portable Notepad++ yet. I just have Notepad++ installed in Program Files (x86) and after installing NppGTags plugin via Plugins Admin it is put in C:\Users\<user-name>\AppData\Local\Notepad++\plugins.

Is there any other plugin doesn’t work after its installation by Plugins Admin?

Yes, NppGTags is also not functional after installation via Plugins Admin. After Notepad++ restart everything is working as expected.

@dinkumoil ,

Maybe there are other plugins where it is the same

You are correct - NppGTags is also not working without Notepad++ restart at the moment.

There could be required some WM_XXX messages, in the worst case this may be plugin dependent

Hm, those messages should be a consequence of loading a plugin so they should be there.

You have provided a very thorough description of the plugin update problem, good points there.

Well, I agree that if updating a plugin is such a pain then it is not worth the work to make it restart-free so basically I agree with you.

Just as a note about the Plugins menu - I suppose Notepad++ knows which menu entries are connected to which plugin (it has some internal ID) and will remove them on plugin’s behalf when unloading it.

chcg

Maybe an additional flag “RestartRequired” in the json could do the magic to distinguish between plugins updateable on-the-fly and the ones which are not.

donho

@dinkumoil

Good point.
The installation will follow update behaviour - ie. quit Notepad++, install the plugins then restart Notepad++.
All the binaries are updated in the following link:
https://notepad-plus-plus.org/pluginListTestTools/

dinkumoil

@donho

I’ve tested the new binaries. Here are the results.

If the SHA-256 hash of a plugin ZIP file is provided with uppercase letters plugin installation fails, saying that the hash value is wrong and the plugin is about to be deleted. Wouldn’t it be better to check hashes case insensitive?
If the download URL for a plugin ZIP file is wrong plugin installation fails, saying that the hash value is wrong and the plugin is about to be deleted. There should be a better error message pointing to the actual cause of the error.
Portable installations of Npp install plugins under <folder-of-portable-Npp>\plugins\<plugin-name> whereas local installations of Npp install them under <Userprofile>\AppData\Local\Notepad++\plugins\<plugin-name>. The plugins which are packaged with Npp installer are always stored under <Npp-folder>\plugins\<plugin-name>. This is confusing and additionally there is a pitfall when upgrading from Npp 32 bit to Npp 64 bit (local installations) - the plugins for both architectures are stored in the same location (<Userprofile>\AppData\Local\Notepad++\plugins\<plugin-name>) thus at first start of newly installed 64 bit Npp users will be confrontated with a bunch of alert boxes stating that plugin XYZ is not suitable for the current version of Npp.
In these alert boxes users can choose to remove the plugin in question to avoid the same error message at next start of Npp. But the plugin gets not deleted.
In the 32 bit version of the plugin list (pl.x86.json) currently is a syntax error. You left a semicolon instead of a comma before the block of the NppSaveAsAdmin plugin.

Points 3. and 4. make me to ask again if it wouldn’t be better to install plugins in all cases under <Npp-folder>\plugins\<plugin-name>. Plugin installations are performed with a restart now. I guess GUP is actually doing the job to copy plugin files, it would be easy to start it with admin rights (ShellExecute with verb runas) so it is able to copy files even to a subfolder of C:\Program Files.

To cope with the current situation I had to reimplement the function to get the plugin DLL path (which is now identical with the path for all companion files of the plugin, e.g documentation, help files), a code change which has to be done for many other plugins too (with all the problems caused by that fact I already mentioned).

donho

@dinkumoil

Thank you for your tests and pertinent suggestions.

Wouldn’t it be better to check hashes case insensitive?

Done. Both 32/64 bits of GUP.exe are updated and available to download now.

In the 32 bit version of the plugin list (pl.x86.json) currently is a syntax error. You left a semicolon instead of a comma before the block of the NppSaveAsAdmin plugin.

Fixed and committed.

Points 3. and 4. make me to ask again if it wouldn’t be better to install plugins in all cases under <Npp-folder>\plugins<plugin-name>.

The reason of installation to <Userprofile>\AppData\Local\Notepad++\plugins\<plugin-name> is Microsoft’s Universal Windows Platform. A UWP package is immutable so there’s no way to install plugins into Notepad++ installation directory. That says, in the next release while Notepad++ installation if the installation destination is in “Program files”, Notepad++ installer will install the default plugins into <Userprofile>\AppData\Local\Notepad++\plugins\<plugin-name> and Notepad++ loads the plugins only from <Userprofile>\AppData\Local\Notepad++\plugins\<plugin-name>.

dinkumoil

@donho said:

The reason of installation to <Userprofile>\AppData\Local\Notepad++\plugins\<plugin-name> is Microsoft’s Universal Windows Platform.

Ahh, got it. Another suggestion: My current implementation to retrieve the path of the plugin DLL and its companion files is as follows (I ported it from Delphi to C because I’m not a C++ dev):

LPTSTR GetPluginsDir(HMODULE hModule)
{
  LPTSTR szBuf;
  DWORD  dwBufLen;
  DWORD  nCCh;

  dwBufLen = MAX_PATH;  // Initial buffer size, has to be greater than 0
  szBuf    = NULL;      // Buffer memory is allocated in loop

  do
  {
    // Resize buffer and try to get module path
    szBuf = (LPTSTR) realloc(szBuf, dwBufLen * sizeof(*szBuf));
    nCCh  = GetModuleFileName(hModule, szBuf, dwBufLen);

    // If nCCh is 0 there was an error
    //   => leave loop
    // if nCCh is less than dwBufLen the buffer size was sufficient
    //   => leave loop
    // If nCCh is equal to dwBufLen the buffer size was too small
    //   => loop and retry with double sized buffer
    // nCCh greater than dwBufLen is a non-existing case
    if (nCCh < dwBufLen) break;
    dwBufLen *= 2;
  } while (TRUE);

  if (nCCh != 0) // Retrieving path succeeded
  {
    // Resize buffer to desired size
    szBuf = (LPTSTR) realloc(szBuf, (nCCh + 1) * sizeof(*szBuf));
  }
  else // Retrieving path failed
  {
    // Free buffer and return NULL
    free(szBuf);
    szBuf = NULL;
  }

  return szBuf;
}

Seems complicated but starting with Windows 10 it is no longer sufficient to deal with MAX_PATH to allocate buffers for file paths since they can be longer now. When writing the code I had in mind to cover all possible installation scenarios for Npp. A portable installation can be located in a deeply nested path, thus the loop for buffer allocation.

But for the most part, the bad design of the GetModuleFileName API is to blame for the complicated code. Would you please provide a Npp message which can be used to query the folder of a plugin DLL file? This would make plugin devs life more easy. Ideally it schould be designed like the NPPM_GETFULLPATHFROMBUFFERID call.

donho

@dinkumoil

Ideally it schould be designed like the NPPM_GETFULLPATHFROMBUFFERID call

It’s not clear to me at all. Could you define the API you need by using this form:

	#define NPPM_GETFULLPATHFROMBUFFERID (NPPMSG + 58)
	// INT NPPM_GETFULLPATHFROMBUFFERID(UINT_PTR bufferID, TCHAR *fullFilePath)
	// Get full path file name from a bufferID.
	// Return -1 if the bufferID non existing, otherwise the number of TCHAR copied/to copy
	// User should call it with fullFilePath be NULL to get the number of TCHAR (not including the nul character),
	// allocate fullFilePath with the return values + 1, then call it again to get full path file name

Scott Sumner

It’s not clear to me at all

??

And to think, all this pain was wrought by one little ad in the corner of a window…

dail

Was getting ready to add some of my plugins to the list, however I’m not able to get any installation to work. A few minutes ago I grabbed the notepad++ and gup exes, and the new plugin list json file.

Don’t have any plugins installed
Start notepad++ as administrator
Go to plugin admin, no plugins are listed under “Updates” Or “Installed”
Select DSpellCheck
Click install
Notepad++ says it will restart
Click Ok
Nothing happens
Wait a bit, start N++ manually, nothing is installed

Notepad++ v7.5.9   (32-bit)
Build time : Oct 31 2018 - 19:53:57
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : ON
Local Conf mode : OFF
OS : Windows 7 (64-bit)
Plugins : none

donho

@dail
Could you paste here your plugin entry (32-bits) to add in nppPluginList.cpp ?
I will check it.

dail

@donho

I’m wanting to add these entries (for 32 bit) but have no way to test it currently:

{
	"folder-name": "BetterMultiSelection",
	"display-name": "BetterMultiSelection",
	"version": "1.3",
	"id": "ef3f4e8ffac54fd7e6c9abcd785df09482cba2d63ab68c6bc9bffa71e4053de5",
	"repository": "https://github.com/dail8859/BetterMultiSelection/releases/download/v1.3/BetterMultiSelection_v1.3.zip",
	"description": "Provides better cursor movements when using multiple selections.",
	"author": "Justin Dailey",
	"homepage": "https://github.com/dail8859/BetterMultiSelection"
},
{
	"folder-name": "DoxyIt",
	"display-name": "DoxyIt",
	"version": "0.4.3",
	"id": "401bc3413e90f87baf6d31ceb800e6fe7d8df54fe063fe659c713eddeec8e2f3",
	"repository": "https://github.com/dail8859/DoxyIt/releases/download/v0.4.3/DoxyIt.zip",
	"description": "Support for creating Doxygen comments.",
	"author": "Justin Dailey",
	"homepage": "https://github.com/dail8859/DoxyIt"
},
{
	"folder-name": "ElasticTabstops",
	"display-name": "ElasticTabstops",
	"version": "1.3",
	"id": "6d2d8ba941d060e9caca6bb84e0b3864173b93c164de97b663f66d4998749d3a",
	"repository": "https://github.com/dail8859/ElasticTabstops/releases/download/v1.3/ElasticTabstops.zip",
	"description": "Support for Elastic Tabstops.",
	"author": "Justin Dailey",
	"homepage": "https://github.com/dail8859/ElasticTabstops"
},
{
	"folder-name": "LuaScript",
	"display-name": "LuaScript",
	"version": "0.8",
	"id": "b10c358552ab9d12990c3005e3a45ee0c736587e4025fc1cfd054f1325c9ef46",
	"repository": "https://github.com/dail8859/LuaScript/releases/download/v0.8/LuaScript_v0.8.zip",
	"description": "Adds Lua scripting capabilities. This provides control over all of Scintilla's features and options with a light-weight, fully-functional programming language.",
	"author": "Justin Dailey",
	"homepage": "https://github.com/dail8859/LuaScript"
},
{
	"folder-name": "SurroundSelection",
	"display-name": "SurroundSelection",
	"version": "1.1",
	"id": "632f7411f00aef29ecf565415df79cc4edb6a6518fa620073567d379583d81b8",
	"repository": "https://github.com/dail8859/SurroundSelection/releases/download/v1.1/SurroundSelection.zip",
	"description": "Automatically surround the selection in quotes/brackets/parenthesis/etc.",
	"author": "Justin Dailey",
	"homepage": "https://github.com/dail8859/SurroundSelection"
}

donho

@dail
All passed.
Will you pass me the 64-bits ones so I’ll include them in the nppPluginList for the next release ?