Support for Plugins Admin & NppPluginList

dinkumoil

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.

pnedev

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

dinkumoil

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

donho

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 empty doLocalConf.xml file), 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.

rinku singh

@dinkumoil i think unsupported plugin never delete there after restart npp also

dinkumoil

@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”.

Andriy Astakhov

@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.xml file), et voilà.

As others already mentioned please make Notepad++ be truly portable. Add possibility to have Plugins directory inside Program folder.

konju river

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?

Meta Chuh

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

Meta Chuh

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)

dinkumoil

@Meta-Chuh

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).

dinkumoil

@konju-river

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.

Meta Chuh

@dinkumoil

true.
take it just as a workaround for now, to achieve the desired functionality with what we’ve got at the moment.

i tend to search for solutions to reach a goal with the given, before i think about what could be done to make it better in the future … especially because it takes me very, very long until i really know what could be best or what would have been better to do it another way.

dinkumoil

@donho

There still seems a bug in the unzip-code of GUP.exe. I tried to install the NppSnippets plugin (32 bit variant) via Plugin Admin. This plugin needs some companion files which get unzipped to a subfolder of its directory. One of these files named Languages.sql has a size of 0 bytes after unzipping.

Please note: The plugin itself also has a bug, it isn’t aware of the new plugin hosting model of Notepad++. Thus the subfolder mentioned above has to be copied to <Npp-installation-dir>\plugins in order to get the plugin working. But of course, with the 0-byte-file it will not work either.

Jeffrey Morley

Wow. This is really pretty heavy-handed isn’t it?

So our plugin for Rainmeter code “lexer”, which has worked with Notepad++ like forever, is now not only not working for all our users that upgrade Notepad++, but apparently I have to jump through a ton of hoops and add our plugin to a public list maintained and vetted by you guys in order to make it available?

Our users download the plugin from here:

https://github.com/poiru/rainlexer/releases

And it has an installer that used to put it in the right place to be seen by Notepad++

We have no interest in being hosted or given permission to exist by the team here. We simply want to know how we can have our users locally install a plugin, and have it work.

Jeffrey Morley

Ok, I think I figured it out.

Currently, with Notepad++ 7.5

The plugin file RainLexer.dll is in
C:\Program Files (x86)\Notepad++\plugins\RainLexer.dll

A supporting .xml file is in
C:\Users\YourName\AppData\Roaming\Notepad++\plugins\config\RainLexer.xml

With Notepad++ 7.6 you need to move RainLexer.dll to:

C:\Users\YourName\AppData\Local\Notepad++\plugins\Rainlexer\RainLexer.dll

The .xml file can stay were it is…

dinkumoil

@Jeffrey-Morley said:

I have to … add our plugin to a public list … in order to make it available?

Not sure where you read this…

Jeffrey Morley

@dinkumoil said:

@Jeffrey-Morley said:

I have to … add our plugin to a public list … in order to make it available?

Not sure where you read this…

I shouldn’t have assumed that from the pretty strong push for the plugin-admin feature that seems to encourage it.

It’s still pretty heavy-handed to have an upgrade to the product just invalidate goodness-knows how many local 3rd-party plugins folks have installed in Notepad++ without the installer just automatically moving them to the required new locations or having some backwards-compatible approach that would still use old ones in the old locations while supporting new ones in the new location.

A LOT of people, who just “use” Notepad++, and are not technical, got a big, unpleasant surprise today.

Fake4d

Could someone tell me if it is possible to rescue the PythonScript? https://sourceforge.net/projects/npppythonscript/

Maybe there is a good alternative? I really need that one …

SaturnusDJ

When I want to use the new Npp ‘Plugin Admin’ I have to run notepad++.exe as administrator. Why?