Support for Plugins Admin & NppPluginList
-
@bmg-ruudv said:
I use the 7z package from the website, and extract it in my OneDrive folder. When there is an update of Notepad++, I just overwrite the files with the new files from the 7z package. I use it this way so I can use the exact same version, configuration and plugins on multiple systems that are all synced by OneDrive. Unfortunately, this way of working doesn’t seem to be supported in this new Notepad++ version, is that correct? As this new version seems to create a situation where I have to maintain multiple installations on all these systems, I just reverted to v7.5.9. Is there any way to let Notepad++ use the /plugins/ folder for it’s plugins?
I’m in the same boat as @bmg-ruudv, though with Dropbox, not OneDrive. Would appreciate any advice on what to do if one uses the portable version. Luckily, I didn’t overwrite my Dropbox version. Was testing out 7.6 in its own folder, but I can’t find how to access this Plugins Admin I see mentioned a lot. Nor are any of my non-default plugins working.
-
I have a 64 bit computer running the 32 bit version. I’m behind a firewall and use a proxy server with ID/Pwd (proxy settings are stored in Internet Options). WinGup appears to be failing. When I attempt to install, N++ closes and I see that WinGup is running. After a minute or so, WinGup ends and N++ restarts. But the selected plugin is not installed. Worse, if I try to update an existing plugin, it is uninstalled.
-
@David-Brigden52, I observed the same thing. GUP always removes the plugin before downloading new one. If update is aborted due to any reason e.g. network not available or disconnected in between or downloading is not possible in restricted environment due to https or plugin extraction fails, then you can bring your original plugin from recycle bin. Right click on the required plugin and restore it.
@donho , The above GUP behavior really needs some changes. I feel, plugin should be extracted somewhere in temp and then it should be copied to original destination (either overwrite or delete first then copy. So that in case of any failure as described above, user will not lose existing plugin.
-
How to manage if I use 32bit and 64bit parallel?
Up to now I had seperate Folders for 32bit and 64bit Plugins (%PROGRAMFILES(x86)%\Notepad++\plugins\myAwesomePlugin.dll and %PROGRAMFILES%\Notepad++\plugins\myAwesomePlugin.dll), but with the workaround from Homepage all plugIns are copied to 1 Folder (%LOCALAPPDATA%\Notepad++\plugins\ to create myAwesomePlugin ), that makes Problems with the different Versions. -
Here already is an ongoing discussion concerning this topic.
-
@Sven-Groß , @dinkumoil ,
It might be a bit off-topic but why would you need to have both 32 and 64 bit versions simultaneously?
Why would Notepad++ be built to support it, what is the justification? Do you have other programs co-existing in 32 and 64-bit version on the same computer? -
@pnedev said:
why would you need to have both 32 and 64 bit versions simultaneously?
The simplest answer might be:
- 32-bit for can’t-live-without-plugins that haven’t/won’t make the jump to 64-bit
- 64-bit for larger file capacity
Even better answers might be:
- experimentation / tinkering
- reported bug verification/reproduction in each
- because someone wants to
Regardless, it seems that with a “portable” install of each, one should be allowed to have both and they should be completely independent (sort of implies doLocalConf.xml file is present in each).
-
Thank you for explaining @Scott-Sumner but still that is not good enough reason for me.
Anyway, it’s just a personal opinion and I understand that the less restrictions there are the happier the advanced user.
All depends on how difficult that would be to implement. -
@pnedev said:
All depends on how difficult that would be to implement.
Two directories named x86 and x64 in the plugin folder should be sufficient, not so much effort. To support the supporters here in the forum it would be a nice gesture. They will have a lot of work in the next time with users who appear here in the forum and the issue tracker because they are running into problems after updating to Npp v7.6. If you look around you can see it already.
-
@dinkumoil said:
Two directories named x86 and x64 in the plugin folder should be sufficient, not so much effort.
OK, and what about the plugins having to guess the path of their companion libraries?
Now we have the new Notepad++ message to get the plugins location BUT it has to be made version-specific (32 or 64 bit), correct?So in one case the message should return
%LOCALAPPDATA%\Notepad++\plugins\x86
and in the other
%LOCALAPPDATA%\Notepad++\plugins\x64.@donho ,
All this change of plugins residence is becoming very complicated and all Notepad++ files are getting scattered across various places making things confusing. At least that’s my impression. Is it really necessary?
-
@pnedev said:
Now we have the new Notepad++ message to get the plugins location BUT it has to be made version-specific
You are right. My first suggestion concerning this message was to return the complete path to the plugin DLL file. But Don liked it to be more simple, thus I accepted his regarding suggestion. Now I have to admit that it was wrong to give up discussing about this point so soon.
-
I understand totally why your demand of 32/64 plugins folder so for the power users they could keep both architectures of Notepad++.
It’s indeed possible by making at least one Notepad++ in another directory and set it as potable version (by adding an emptydoLocalConf.xmlfile), et voilà.The true question is “why do we need both 32/64 bits Notepad++ in the same PC ?”. If it’s a spoiled answer like “because I want to” - in order to keep the logic as simple as possible for the maintenance reason, the answer is NO.
-
@dinkumoil i think unsupported plugin never delete there after restart npp also
-
@donho said:
The true question is “why do we need both 32/64 bits Notepad++ in the same PC ?”. If it’s a spoiled answer like “because I want to” … the answer is NO.
@Scott-Sumner already gave you some reasonable answers, see his comment above. Only one of these is a “because I want to”.
-
@donho said:
It’s indeed possible by making at least one Notepad++ in another directory and set it as potable version (by adding an empty
doLocalConf.xmlfile), et voilà.As others already mentioned please make Notepad++ be truly portable. Add possibility to have Plugins directory inside Program folder.
-
I downloaded the x64 zip and extracted it to d:\tools\npp. Then i started it with notepad++.exe.
When I now go to Menu->Plugins there is no Plugins Admin?
When I install it per msi file, then the Plugins Admin is there.
Where can I configure, that Plugins Admin should use the Directory, from where notepad++.exe is called?
Is that possible? -
@Scott-Sumner @Sven-Groß @dinkumoil and anyone else wanting both np++ x64 and x86 with functioning plugins admin
you can install both np++ x86 and x64 simultaneously, even if you are using the installer package:
create a directory (needs to be outside of Program Files and Program files (x86))
eg.: C:\Applications
install x86 to “C:\Applications\Notepad++ x86” and check “Do not use %APPDATA%”
install X64 to “C:\Applications\Notepad++ x64” and check “Do not use %APPDATA%”all plugins and plugins admin will be separate and available for all users inside of “C:\Applications\Notepad++ x…\plugins”
important: it has to be outside any %PROGRAMFILES% path (_isInProgramFiles) or the DoLocalConf.xml will not work as _isLocal is overridden if _winVersion >= WV_VISTA
@donho
do you have an idea what to do with the installer option “Do not use %APPDATA%” ?
while it does trigger the installer to move everything into the np++ folder, the uac failsafe “if (_winVersion >= WV_VISTA)” prevents it from working if _isInProgramFiles.the “Do not use %APPDATA%” option is a bit confusing at the moment, because the installer uses the desired paths, but np++ overrides if _isInProgramFiles, so no plugins that have been copied by the installer are seen
the only “simple” idea i can come up with is to parse match the installation path selected in the installer and grey out the installer option “Do not use %APPDATA%” if the selected path is within any %PROGRAMFILES%
-
supplement:
if you are running multi users without admin rights, make sure that all desired users have r or r/w rights on C:\Applications… depending if you just want them to use or also be able to install plugins.
(keep in mind that plugins that write temporary files to the plugins folder itself will only work with r/w) -
Thank you for the explanation. But this covers only the case where a user demands the “dual architecture” feature because of “he wants it”.
I thought of supporting users here in the forum, in this case it can be important that you (as supporter) can use a standard installation of Notepad++ to verify/reproduce user’s bugs.
A “dual architecture” installation can be considered as a standard installation because the two Npp version would not interfere (except that you have to decide which version should be started via Explorer context menu entry and in cases where it comes to file type associations).
-
Portable installations from a ZIP package are currently not equipped with Plugin Admin.
If you use a local installation from an installer EXE/MSI and want the plugins to be located in this directory instead of %LocalAppData% please read the postings of @Meta-Chuh above.
