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

dinkumoil · Oct 29, 2018, 11:33 AM

a plugin named, say, abcde.dll :

It should b placed in the folder ..\Plugins\abcde

That is correct.

All other files and folders, necessary for the plugin, which were, initially located under ..\Plugins\Config\abcde ( or elsewhere ! ), will, now, be located under ..\Plugins\abcde

No, files in the config folder stay there. Nothing changes.

And so, in the long run, the config directory should disappear, shouldn’t it ?

Personally, I think that, if this new organization were implemented, it would be better because everything, regarding, for instance, the abcde.dll plugin, would be included in its own folder ..\Plugins\abcde :-))

This would be a bad idea. At least for local installations of Npp the plugins own folder is stored in a proteced location (usually C:\Program Files\Notepad++\plugins\abcde). Thus the plugin wouldn’t be able to write to its own config file(s) because admin rights would be required to do that.

guy038 · Oct 29, 2018, 12:06 PM

Hi @dail,

Thanks, for all your clarifications :-)

Regarding my last statement, I’m so used to have, on my laptop, several versions of N++, at a time, all located in a user-defined folder, not related with any system-protected area that I had just forgotten the particular case you were talking about !

donho · Oct 29, 2018, 12:13 PM

@dinkumoil said:

After testing the new binaries I want to precise this statement according to my experience.

The plugin DLL file should be placed at the root level of the ZIP file. It has to be the only DLL file on this level.
The root level of the ZIP file can also contain additional files and folders which will be copied to the users harddisk as well.
Everything what gets copied from the ZIP file will be stored under <Npp-installation-folder>\plugins<plugin-name>.
Presumption: Additional DLL files needed by the plugin have to be placed in an arbitrary subfolder because the destination folder <plugin-name> gets named after the DLL file placed on the ZIP root level.

Very accurate description you made. It will be included in the PA guide line if I’m allowed to use it.

dinkumoil · Oct 29, 2018, 12:25 PM

@donho said:

It will be included in the PA guide line if I’m allowed to use it.

Of course, feel free to do that.

Hsilgos · Oct 29, 2018, 4:04 PM

Are you sure you did your last changes to both versions of GUP and Android++?
For me seems that x64 works with new scheme, but x86 works with old

dinkumoil · Oct 29, 2018, 4:11 PM

@Hsilgos said:

For me seems that x64 works with new scheme, but x86 works with old

I’ve tested both 32 bit and 64 bit Notepad++ and both worked with the new scheme.

donho · Oct 29, 2018, 5:52 PM

@Hsilgos

Are you sure you did your last changes to both versions of GUP and Android++?
For me seems that x64 works with new scheme, but x86 works with old

Because you use Android++ instead of Notepad++.

Hsilgos · Oct 29, 2018, 6:03 PM

@donho Yes, Notepad++ for sure =D
The rest of message should be correct

donho · Oct 29, 2018, 8:24 PM

@dinkumoil Sorry, I didn’t read your description attentively. The correct info about packaging is following:

The plugin DLL file should be placed at the root level of the ZIP file.
The root level of the ZIP file can also contain additional files (DLL files or data files needed by the plugin) and folders which will be copied to the users harddisk as well.
Everything what gets copied from the ZIP file will be stored under <Npp-installation-folder>\plugins<plugin-name>.

The other DLLs can be at the root level with plugins DLL because Notepad++ will load only the dll has the same name as its containing folder. The other DLLs are just ignored.

chcg · Oct 29, 2018, 10:50 PM

Having a hash of the main plugin dll might be still of interest, if you want to provide a “safe” mode with just starting plugin dlls with correct sha-256 hash.

pnedev · Oct 30, 2018, 8:39 AM

@donho ,

I just noticed that when testing the NppGTags x86 plugin installation it was put in C:\Users\me\AppData\Local\Notepad++\plugins\NppGTags instead of C:\Program Files (x86)\Notepad++\plugins\NppGTags. It is working fine but I didn’t get the impression that it would be installed there.
Is that the intended behavior?

dinkumoil · Oct 30, 2018, 2:10 PM

@pnedev said:

it was put in C:\Users\me\AppData\Local\Notepad++\plugins\NppGTags instead of C:\Program Files (x86)\Notepad++\plugins\NppGTags

I did my previous test with portable installations of NPP, with a local installation I can confirm this behaviour. My plugins partially fail to work correctly, they don’t find their own DLL (required for extracting version information for the About box) and their documentation file anymore.

The current behaviour is caused by the fact that it was intentional to provide a method of plugin installation which requires no restart of Npp. Thus the plugin installer can’t copy the plugin files to the installation folder of Npp because usually this is a protected location and would require admin rights to do so.

Since we already discovered that there is a high risc that a restart-free plugin installation will cause problems with certain plugins (NppFTP seems to be one of these) @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.

donho · Oct 30, 2018, 2:24 PM

@pnedev

Is that the intended behavior?

Yes, I confirm it.
From now on all plugins will be placed in its folder which has the same name, so that any data or dll that plugin needs can be placed arbitrarily in this folder.

I invite you to check the guide for being included in plugins list , it’ll be updated as soon as there’s any change of specs.

donho · Oct 30, 2018, 2:32 PM

@dinkumoil

@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 · Oct 30, 2018, 3:16 PM

@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 · Oct 30, 2018, 4:39 PM

@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 · Oct 30, 2018, 4:52 PM

@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 · Oct 30, 2018, 6:37 PM

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 · Oct 31, 2018, 9:28 AM

@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 · Oct 31, 2018, 12:38 PM

@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?