User directory for .nss settings overrides instead of Program Files

[stamminator]

The only way I've been able make changes to NSS's configuration has been to modify files in the main app directory.

I'm sure there are technical factors I haven't considered, but in my opinion, rather than modifying files in Program Files, it would be much better for settings customizations to live in a user-level folder as overrides to defaults defined in Program Files. This would have a few advantages:

1. It's clear to the user that their settings won't get lost when updating.
2. We're free to muck around with settings without fear of screwing up our install or needing to manually manage our own backups.
3. Users on multi-user machines could each have their own settings (I suppose this is already possible by installing with scoop, albeit with separate installs)
4. If a GUI editor for the settings ever becomes feasible, it could support showing a diff between the default setting and the user override. This would drastically simplify NSS's setup process and lower the barrier of entry for less technical users.

Do you think this idea is viable? Why or why not? What factors might I be overlooking?

Thank you for your work on this app, @moudey!

[RubicBG]

I will share my opinion and some workarounds to deal with the situation:

• Тhe program "must" be accessible to the most uneducated - there are "kids" who know how to install the game and play, there are people who know how to install an archiver and how to use it, ... no matter what example I give, none of them understand coding/programming - they are ordinary users. Ordinary users know a few "basic" things: directories like Windows and Program Files should not be touched, directories like Documents everything is allowed. If the nss files are moved to a more accessible folder, the probability of ruining the work of the program is high. The ordinary user also knows that when reinstalling the program "fixes" itself" - this means that the .nss files must be overwritten

• NS works with its own script, which continues to develop. Until version 1.8, a syntax with "static{ }" and "dynamic{ }" was used - this syntax is dropped, dynamic{ item( ) } is converted to modify{ } - here again the .nss files are required to be overwritten. not everyone reads the documentation to be aware.

• Тhe easiest way to redirect nss files: Create folder "Nilesoft Shell" in "C:\", copy "shell.nss" and "import" directory to newly created folder "C:\Nilesoft Shell", open "C:\Program Files\Nilesoft Shell\shell.nss", delete everything in it and add only this line:

import 'C:\Nilesoft Shell\shell.nss'

• To edit the nss files it is not necessary to go to the installation directory every time. Example with VS Code:

item(title='Visual Studio Code' image=[\uE272, #22A7F2] cmd='code' args='"@app.directory"' window=hidden)

• Creating a copy as a backup before installation - this is already taken into account

[MrLint]

If the issue is the concern that a user will break the settings because it would be in ~/Documents, there are a number of other ways to address this. The appdata subfolders are already hidden by default, and still provide a per user location. For the 'uneducated' this is an all but impenetrable wall that would prevent haphazard 'tampering'. Additionally putting items in to the root is generally not recommended, and depending on setup is not writeable by non-admin users.

[MrLint]

I am someone who implements strict privilege separation on all my systems. The settings for the shell being in program files does create an extra chore to do customization. I would like to see a setup in which the bare bones defaults can be read out of PF, and that is the skeleton for per user settings in the user's app data folder.

There is of course the issue of a multi user system in which you'd want an admin managed central settings; off the top of my head I feel this would be a limited use case.
Thank you

[RubicBG]

I didn't realize that NS was designed as a portable program until recently. By default, all files are launched from (or located in) a single folder. The concept of installation came later, which is why you'll find shell.nss in the Program Files - it's a result of that evolution.

There is a registry setting (undocumented) that changes the path to shell.nss.

[HKEY_CURRENT_USER\Software\Nilesoft\Shell]
"config"="C:\\Shell\\shell.nss"

For multi-user modes - this can be configured in shell.nss (I haven't done it yet)