New Plugins Home (Round 2)

V S Rawat

My suggestion was:

The way you are now giving a “<PLUGINS_HOME>” variable, you should also please consider giving a “<USERS_HOME>” variable that a user can set to move his entire c:\USERS<name>\APPDATA\Roaming\npp folder (or whatever the structure is) to elsewhere.

then, in my case, I will move that to E:\MyData\npp\profile folder.

Then, plugins’ c:\USERS location will automatically move to the above location.

Then I can use the same npp <USERS_HOME> across my w10 and w8.1 multiboot.

please have a look to firefox, thunderbird arrangements for moving entire user profile that way. My firefox profile is in E:\MyData\ff\ffprofile and My Thunderbird profile is in E:\MyData\tb\tbprofile and I have been using them for 10-20 years, across multiboot o.s.

Thanks.

V S Rawat

I personally find the entire concept of doLocalConf.xml confusing and unnecessary.

new users must be getting confused about that, most might not be knowing that even for years of use of npp, the way it had been for me for years.

it should be done through a single variable in .ini file.

Would you like to share what is the benefit of this file over an .ini setting?

Thanks.

V S Rawat

Many users don’t know what plugin is, and they will never use a plugin for years of using npp, so there is no point in making every user take the important decision about placement of plugins in programfiles or users\roaming right at the time of installation.

And once the user has made any decision in absence of full knowledge of the issue, there is no easy and obvious method of changing that from within npp settings.

I think this entire question about plugin location should be removed from installer, and the user should be able to install npp like he/ she installs other windows software, without having to making a tough far fetching decision right in the middle of first install.

Then, user should be able to decide from within npp settings, where he wants to keep plugins, if he ever wants to use a plugin. Otherwise, may be the user will never need to make such a decision for his entire life.

If a user changes the location of plugin_home or users_home from within npp settings, he should be asked whether he wants the existing contents of old folder to be moved to new location, and if he says so, it should be done. That new location might already have users previous setup of previous npp, if so, user should be warned that there are already similar files that would be overwritten, and he should be able to choose whether to copy/ move or not.

Thanks.

V S Rawat

I am not comfortable with the suggestion of Meta Chuh and pnedev about “extra sub-folder per plugin” made in other thread.

every plugin should have one .dll then it can be kept without needing any folder hierarchy structure.

And most plugins do have a single .dll, except some, say, pythonscript.

But then the developers can define within the single plugin.dll where the other dlls or other help files or other installation files can be found, so why cramp plugin folder?

Even if a plugin has several dlls and one or more help or other files, plugin developers can name them with plugin’s initials, say, pyscript1.dll, pyscript2.dll, pyscript.hlp, meaning that ll files of a plugin should come together and should be identifiable readily by the user with plugin’s name. then users will not find any problem.

I think pyscript plugin has another file that has no relation to plugin name and we have to figure out where that came from and whether it is safe.

So, my suggestion is to remove that pluginnamefolder/pluginname.dll compulsion

billions of people in the world live in shared house and shared room, every human is not having his own single occupancy house or room, so why not get used to that common trend. :-) maybe if npp policy is followed, husband and wife will have to sleep in different rooms. :-)

Thanks.

Meta Chuh

hi @V-S-Rawat

I personally find the entire concept of doLocalConf.xml confusing and unnecessary.

i understand what you mean, but it is imperative that it exists in the way it does now.

a little explanation:
if you don’t have doLocalConf.xml present at startup, notepad++ would look for a config.xml file inside of %AppData%\Notepad++\ to read it’s settings.
if it does not exist, it will create one.
now if the dolocalconf setting is within the config.xml, it would cause a paradoxon, as notepad++ would look up at %AppData% that it should behave as a “portable” version which is supposed to get it’s config from %InstDir% instead of %AppData%.

the existence of a file called doLocalConf.xml triggers notepad++ to read and create everything within it’s own folder, and it also triggers where notepad++ will read it’s config file from (and create/write to).

V S Rawat

I might have a 64 bit w10, and might have 32 bit w8, and I may have npp 32/64 bit in those.

so, if <pluginin_home> is single in both o.s, npp, I wil face problems when using same npp installation in both o.s.

of course, if I manually define different <plugin_home> for both o.s., but then if you are also considering to define a new <USERS_HOME>, then <plugin_home> will become fixed relative to this variable, and that single location can’t have both 32 and 64 bit plugins together.

so, my suggestion is while defining default <plugin_home>, it will become required if that can be kept separate for 32-bit and 64-bit, and future 128-bit and 256-bit so on.

Thanks.

V S Rawat

@Meta-Chuh

But npp.ini (whatever the name is) has to remain in npp’s intallation folder in program files.

Why keep npp.ini file to a different location?

Even if we have kept a copy of our previous npp.ini file safe in our pc or in backup, we can copy that single file to npp’s intallation folder after installing it, then it can read all things from there.

Then how does that local.xml file help over .ini file. We have to create/ copy xml file also once?

Meta Chuh

@V-S-Rawat

Many users don’t know what plugin is, and they will never use a plugin for years of using npp, so there is no point in making every user take the important decision about placement of plugins in programfiles or users\roaming right at the time of installation.

that’s one of the reasons why a built in plugins admin exists now.
plugins admin will make sure that the users you mentioned, don’t have to care where to put their plugins, and it will put the (re)installed plugins to the correct locations, even if the location changes, as it is built from the same developers that decide the folder structures.

Meta Chuh

@V-S-Rawat said:

I am not comfortable with the suggestion of Meta Chuh and pnedev about “extra sub-folder per plugin” made in other thread.
every plugin should have one .dll then it can be kept without needing any folder hierarchy structure.

yes i know, and i understand your primary reasons, to keep the old plugins structure as it was, because all older plugins will just work out of the box, just the way they’ve always worked.

but i think you’ll like the new structure, once all transitions are over and everything has calmed down a bit.
and we will help you through your needs as always, like you are used to, to keep your system running.

Meta Chuh

@V-S-Rawat said:

I might have a 64 bit w10, and might have 32 bit w8, and I may have npp 32/64 bit in those.
so, if <pluginin_home> is single in both o.s, npp, I wil face problems when using same npp installation in both o.s.

yes, as i’ve seen at the latest builds, your wish has been granted ;-)
all plugins will (again) reside in their respective x86 or 64 bit program folders and will not get in conflict with each other.

But npp.ini (whatever the name is) has to remain in npp’s intallation folder in program files.
Why keep npp.ini file to a different location?

because non administrator users don’t have the permission to write to %ProgramFiles% and %ProgramFiles(x86)% and therefore would not be able to make any config changes without the help of an administrator … and administrators usually don’t like to be called for every little font change one of his users thinks he needs right now 😉

btw: wow, today you write more posts, questions or requests … and much faster than anyone can answer 😂😂😂

side note:
the config file is called config.xml file located at %AppData%\Notepad++\config.xml of an installed version, and located at npp.7.x.x.bin\config.xml of a portable version.
it’s just like an “ini” file, but with a different, (probably) more readable syntax, as it is more structured and segments are foldable for easier reading if you want to analyse a certain part of it.

V S Rawat

@Meta-Chuh said:

yes, as i’ve seen at the latest builds,

latest builds? how do you get them? beta testing or RC? Privileged one. :-)

download page still has Jan 1 release when I last saw that.

Thanks.

V S Rawat

@Meta-Chuh said:

@V-S-Rawat said:

But npp.ini (whatever the name is) has to remain in npp’s intallation folder in program files.
Why keep npp.ini file to a different location?

because non administrator users don’t have the permission to write to %ProgramFiles% and %ProgramFiles(x86)% and therefore would not be able to make any config changes without the help of an administrator … and administrators usually don’t like to be called for every little font change one of his users thinks he needs right now 😉

if so, then METHINK there should be

one configAdmin.xml that only Admin can change and that can be put in npp install folder, users don’ t change that.
another configUser.xml that the user can keep at wherever location and the user should be able to change it without disturbing Admin.

both files should have settings that Admin or user respectively need to change. fonts etc can be in configUser. xml.

Thanks.

V S Rawat

@Meta-Chuh said:

@V-S-Rawat said:

btw: wow, today you write more posts, questions or requests … and much faster than anyone can answer 😂😂😂

Thanks for the compliment. :-)
(pretending as if I didn’t understand that it was actually a complain. :-) :-) )

V S Rawat

@Meta-Chuh said:

side note:
the config file is called config.xml file located at %AppData%\Notepad++\config.xml of an installed version, and located at npp.7.x.x.bin\config.xml of a portable version.
it’s just like an “ini” file, but with a different, (probably) more readable syntax, as it is more structured and segments are foldable for easier reading if you want to analyse a certain part of it.

disagree.

xml files have hard fixed structures and use additional terms that are strange to non-programmer users.

ini files are normal text files that are easy, having
[Sectionname]
Variable1=value1
Variable2=value2

These are much easier to understand and edit by a common user who doesn’t know any programming.

by making elementary use of npp difficult to non-programmer users, we are limiting npp’s prevalence and popularity.

My this complain is million time amplified for defining shortcuts and creating macros due to the xml structure.

Thanks.

Meta Chuh

@V-S-Rawat

if you don’t want to compile notepad++ yourself, you can go to the notepad++ commit page at github like shown on the screenshot below, and do a mouse click on the green “check” on any commit that might interest you.

Imgur

after you clicked the green check, press “details” which will lead you to the appveyor page as seen on the next screenshot.

Imgur

there you click on your desired release configuration, like Configuration: Unicode Release; Platform: x64 and click on artifacts on the left as seen here:

Imgur

now click on Notepad++.X64.Unicode Release.exe of this example to download it, and copy it to your notepad++ install or portable folder (same place where your current notepad++.exe is located).

now start notepad++ by double clicking on the Notepad++.X64.Unicode Release.exe that you’ve just placed there.

… happy testing 😉😉

V S Rawat

Thanks for elaborate guidance, I was not aware of that.

But why should I do it? What is a markup language and how does that help me in which of my requirements? (By any chance, are you believing me to be a computer wizard? Wrong assumption, dear sir :-) )

Thanks.

Meta Chuh

@V-S-Rawat

But why should I do it? What is a markup language and how does that help me in which of my requirements? (By any chance, are you believing me to be a computer wizard? Wrong assumption, dear sir :-) )

you asked:

latest builds? how do you get them? beta testing or RC? Privileged one. :-)
download page still has Jan 1 release when I last saw that.

and you get an answer, that’s the way it should work 😉

btw: due to your tourette posting syndrom of today 😂😂😂, i’d suggest it’s better if you open your own thread for any further of your personal questions, this one is getting quite unreadable.
(my apologies to all readers)

Shamu35 NPP

How to Install plugins as non administrator user?

Option:
Install NPP into “%ProgramFilesx86%”. But during install or upgrade of a plugin, there will be displayed an UAC dialog which prompts for an admin accout. Therefore this is not a possible option.
Option:
Install NPP into “C:\Notepad++” and add “doLocalConf.xml” into this folder. Additionally give write access for the users group for this folder. The users (non administrators) are now able to install or upgrade plugins without an UAC prompt.
So far so good, but the main problem is, that now the configuration files are also located in “C:\Notepad++” and not in the userprofile anymore.
This leads to problems on shared computers which are used by different users. They don’t have their own configuration of NPP anymore.

Is there a different solution which I don’t know for solving this problem?
The main requirement is: Our users (which are not admins) should be able to install plugins by themselves.

Artem Sh.

@Shamu35-NPP said:

The main requirement is: Our users (which are not admins) should be able to install plugins by themselves.

This is critical for us as well.

PeterJones

@Shamu35-NPP & @Artem-Sh :

If it is critical for users to be able to install plugins by themselves, either give them local-administrator privileges, or install in an alternate location: if you use the installer, but put it in (say) c:\usr\apps\Notepad++ instead of c:\program files\notepad++, then they should have the write privileges necessary to install plugins themselves.

The reason I suggest this workaround, rather than agree that it should be changed: you aren’t the only one with a critical requirement. Others have a security-critical requirement of users not being able to install plugins, which is the exact opposite of your requirement. So, if you have admin privileges locked down, the options are to install into program files to protect notepad++ and prevent user-installed plugins, or install somewhere else with write-privileges to allow user-installed plugins, or to use a portable edition with doLocalConfig.xml to keep everything bundled in one writeable directory (or protected directory, if that’s what you prefer).

My workplace uses Avecto Defendpoint (and I’m sure there are other similar), which allows locking down certain Admin tasks, but allowing others; so, when I try a UAC action, Avecto Defendpoint checks my privileges, and if I’m allowed to do that local-admin task, it lets me, otherwise it prevents me. Maybe something like that would work to grant partial Admin privileges to your users. I am not an expert on the IT/Admin side of things, so that’s about as much about Avecto Defendpoint as I know.