Notepad++ 7.6.1

dinkumoil

Regarding APIs directory: As far as I know there are plugins wich are indeed lexers for a certain language. I actually found the WLangLexer which is part of the plugin list of old Plugin Manager. This plugin requests during its installation to copy an XML file to plugins\APIs.

I don’t use lexer plugins, thus I don’t know anything about them. But I think further investigations have to be done before making a decision regarding plugins and plugins\APIs directories.

pnedev

Good point @dinkumoil ,
I don’t use additional lexers and missed that subtlety totally.

@donho ,

I just tried installing SessionManager plugin through 7.6.1 Plugin Admin - Notepad++ restarted but the plugin did not install. There wasn’t any notification about that failure. I believe we need to have some kind of status on plugin’s install - success, fail, progress…

Do you guys experience the same or it is again due to me using Wine?

pnedev

BTW, SessionMgr-1.4.2-plugin.zip stays as zero-bytes file in my user’s Temp folder after the installation fail. We should remove the plugin’s zip after the fail as well @donho .

pnedev

@donho , @dinkumoil , @Meta-Chuh ,

Perhaps the APIs sub-folder needs to be located also in %PROGRAMDATA% :
%PROGRAMDATA%\Notepad++\APIs
instead of
%PROGRAMFILES%\Notepad++\plugins\APIs
because of what @dinkumoil just pointed above - some lexer plugins might want to add some files to APIs as well.

dinkumoil

@pnedev

I miss installation progress too and when a plugin installation/update failed I was facing error messages that stated the wrong reason for that.

I already requested user feedback some weeks ago (see here). And @SinghRajenM has put some effort in writing code that extends GUP.exe to do so (see here and here). But for what ever reasons these PRs have been closed.

dinkumoil

@pnedev

We should remove the plugin’s zip after the fail as well @donho .

No! Gup.exe should be fixed. The plugin is the victim and not the cause of this error.

pnedev

@dinkumoil said:

… I was facing error messages that stated the wrong reason for that.

I assume Wine is the reason why I don’t get the error notifications then, thanks.

No! Gup.exe should be fixed. …

OK, it is perhaps this post of yours.

Meta Chuh

@pnedev

I would prefer though to have
%PROGRAMFILES(x86)%\Notepad++\APIs
instead of
%PROGRAMFILES(x86)%\Notepad++\plugins\APIs

it would be a cleaner, more logical structure, but at the moment there are many scenarios where it can break a functionality if you update an older installation, if they are not considered prior to coding the path changes, and i guess this means a lot of coding work for a cleanup which few people will ever notice or appreciate.

BTW, SessionMgr-1.4.2-plugin.zip stays as zero-bytes file in my user’s Temp folder after the installation fail.

it installs fine for me, but it is missing the menu title on both windows and osx.
alt

@donho
thanks again for the wine path and installer mods, all works like a charm so far. 👍

pnedev

@Meta-Chuh said:

it installs fine for me, but it is missing the menu title on both windows and osx.

It is Session Manager’s known issue that is fixed but not officially merged.

graphixillusion

I’m trying the new version, the portable one, but i can’t see the plugin manager anywhere. Any clue?

Ketrel

I cannot install any plugins in 7.6.1.
I load plugin admin, select the plugin I want, and choose install.

It tells me the program will need to be restarted.
I select ok, and then it closes, and launches a UAP prompt.
I approve that, and then the updater tells me there’s an updated version of Notepad++

If I say yes, it tries to install 7.5.9.
If I say no, it closes and does nothing further.

Upon manually reopening, the plugin I selected is NOT installed.

SinghRajenM

@dinkumoil said:

@pnedev

I miss installation progress too and when a plugin installation/update failed I was facing error messages that stated the wrong reason for that.

I already requested user feedback some weeks ago (see here). And @SinghRajenM has put some effort in writing code that extends GUP.exe to do so (see here and here). But for what ever reasons these PRs have been closed.

Not only this, but are other flaws too -

npp instance should not closed till operation is successful.
plugin admin can have one more column in it which will guide about current state of action of a plugin (e.g. downloading plugin or restart npp to take effect so on).
As all demanded, plugin admin can have progress bar which should interact with gup.exe using IPC to get the current downloaded size. Or something similar mechanism to accomplish it.

Cases:

Add: If a plugin is being downloaded first time, there is not point to close npp instance. download the plugin, then extract it to plugin install directory. Later ask user to restart to take immediate effect. However, on next restart the plugin will be activated by default.
Remove: simply move (using move api) the plugin dll from the install dir to %temp% and once done, ask user to restart. If user does not restart to take immediate effect, otherwise on next restart it will be effected anyway.
Update: First follow “remove” case strategy and then follow “add” case. Once both the cases done, ask user to restart npp or anyway it will take effect on next restart.

Of-cource failures should be handled for all the cases. And all the cases, extra column can content current progress.

chcg

@donho See https://github.com/notepad-plus-plus/wingup/pull/8 for the unzip issue. It fixes at least some aspects of the problem, also still some files are empty.

dinkumoil

@SinghRajenM said:

npp instance should not closed till operation is successful.

Good point, currently there is taken no means to prevent the user from restarting Notepad++ manually in the middle of plugin installation/update.

Imagine a plugin download takes a long time because of slow responding servers and the plugin DLL file is only written as a half. The user gets unpatient and starts Notepad++ manually -> crash, user is unhappy, complains here in the forum and tells his friends that Notepad++ is garbage.

On the other hand I have no idea how to prevent the OS to run a new instance of Notepad++. In the moment a piece of software can detect that a new Notepad++ process is running it is already too late.

plugin admin can have one more column in it which will guide about current state of action of a plugin (e.g. downloading plugin or restart npp to take effect so on).

As all demanded, plugin admin can have progress bar which should interact with gup.exe using IPC to get the current downloaded size. Or something similar mechanism to accomplish it.

Would be really good to have, but I’m afraid that it violates the KISS approach of @donho and thus we will never get it.

Remove: simply move (using move api) the plugin dll from the install dir to %temp%

I don’t agree. I think it is not possible or at least not a good idea to move a plugin DLL file while it is in use.

I think it’s worth to rethink about the whole concept of the plugin update process.

The download of plugin ZIP packages should be done by Notepad++ itself. This way it would be easy to provide a progress bar, meaningful error messages which reflect the real cause of an error and it would prevent users from manually restart Notepad++ because they could see that it is still running and does something. The downloaded ZIP packages should be stored to a subdirectory of the %TEMP% directory.
After downloading the ZIP packages, Notepad++ should start a helper program, depending on the installation scenario of Notepad++ with or without elevated rights, and terminates itself. I recommend to write a new software for that, I will explain below why.
The helper has to be called with an information where to find the ZIP packages and where to unpack them. It waits until there is no more running Notepad++ process. Then it loops over all downloaded ZIP packages found in the source directory and unpacks them to the given location. During this phase it displays a progress bar to provide user feedback.
Finally the helper program restarts Notepad++ without elevation.

Why do I think we need a new helper program for that?

The whole thing is a specialized task for updating plugins. GUP.exe was designed to be used as an application updater and it should stay to be that. Currently every change to the plugin updating code bears the risk to break the updating functionality of Notepad++. That alone is a good point to separate these tasks into two programs.

Furthermore we have currently the problem that portable installations of Notepad++ can not be shipped with GUP.exe because it would download an installer version of Notepad++ when users click to (menu) ? -> Update Notepad++. With a separate program for plugin updates this would be no issue anymore.

BTW: It is really annoying to explain users her in the forum again and again why portable versions do not contain Plugin Admin, this should be fixed ASAP, it doesn’t matter in which way.

A Former User

@donho
Hello, the Plugins Admin is not supported on Windows XP. GUP.exe calls a function named GetTickCount64 which is implemented in the kernel dll starting from Windows Vista. There is a GetTickCount function which returns a double word, so the elapsed milliseconds are limited up to 49.7 days, but this is better than nothing. Or is there any other function that can “replace” what GetTickCount64 function for WinXP? A quick fix would be to use the dword function if notepad++ is running on XP or older Windows . . .

Meta Chuh

@graphixillusion

the portable version does not contain plugins admin.
you’ll have to install the full version to get the full functionality for now.

dinkumoil

@donho

I tested in a VM to install Notepad++ as a normal Windows user. I found that it is only possible to update the plugin list when logged in as an administrator. Furthermore the installer does not create the directory %UserProfile%\AppData\Roaming\Notepad++\plugins\Config which caused crashes of Notepad++ itself when terminating it and also various plugins caused crashes.

What I did

I created a standard user account and installed Notepad++ to %ProgramFiles(x86)% (OS: Windows 7 x64). I copied the plugin list under %ProgramData%\Notepad++\plugins\Config to the desktop. Then I tried to overwrite the file at its original location with this copy. This is equivalent to overwrite the plugin list with an updated version downloaded from the internet. An UAC dialog poped up and required me to input administrator credentials.

When I looked in Windows Explorer to the Security tab of the plugins\Config directory properties it showed access rights for normal Windows users as usual, no write access available. It’s the same with the nppPluginList.dll itself.

Furthermore I was faced with crashes of Notepad++ when terminating it. Also various plugins I installed via Plugin Admin caused a crash. It stops after I have installed the NppFTP plugin. The reason was that this plugin creates the directory %UserProfile%\AppData\Roaming\Notepad++\plugins\Config which did not exist after installation of Notepad++.

I would say: It’s time for a new release. :-(

Artur Harison

Plugins are not UNinstall from %ProgramData% only manual removal.
Or, when running as Administrator.

dinkumoil

@Artur-Hareson said:

Or, when running as Administrator.

That is the intended behaviour. As normal user you should not be able to install, uninstall or update plugins. And it is indeed not possible to do that using Plugin Admin because it causes to pop up an UAC prompt where you have to provide credentials of an admin user.

Artur Harison

I can use Admin mode. But then i can’t use Drag and Drop in field NP++.
I can’t get rid of it. )))