Chocolatey package

[zufuliu]

改名之后建一个 Chocolatey 包吧，Notepad3 已经在上面了
https://community.chocolatey.org/packages?q=notepad2

Originally posted by @Mapaler in #346 (comment)

[Mapaler]

https://docs.chocolatey.org/en-us/create/
文档都是英文的，看不懂

[teknowledgist]

I am the maintainer of the Notepad3 Chocolatey package (and many other packages), and I would be happy to establish/maintain a package for this Notepad2 fork.

As a long time package creator who is fairly familiar with the culture of the public repository, I don't think this fork should supplant the Notepad2 (original) or Notepad2-mod packages. I would much prefer to start a new package using the new name, whatever that will be.

I will want to make the package a machine-wide install because in my experience (personally and in my real job), using Chocolatey for user installs ends up with a giant mess. (IMHO, at a minimum, even single-user machines should have an unprivileged, "daily driver" user which means, when the admin account runs a Chocolatey install, it is not available to the unprivileged user.) That means, either the INI file location needs to be in %USERPROFILE% by default, or I have to create the Chocolatey package to manage it (a bit of a PITA).

Let me know your thoughts.

[zufuliu]

I updated #405 (comment) to reflect actual INI folder search order in code (in CheckIniFile() function). Personally I think install the three bundled INI files (copied from https://github.com/zufuliu/notepad2/tree/main/doc and https://github.com/zufuliu/notepad2/tree/main/metapath/doc folders) into one of three folder in %USERPROFILE% would be easy.

[teknowledgist]

My thinking is that it will be easier to uncomment the first two lines of Notepad2.ini in the program directory. That way, upgrades don't need to worry about checking for and/or overwriting individual user preferences.

What happens if the Notepad2.ini directs Notepad2 to use/save preferences in the user profile but there are no settings files in the user profile? Does Notepad2 create the files as needed in the proper location?

Also, I need to know the new "official" name. It's your project, and you've gotten comments on suggested names. In the end, you just have to pick something because nothing will please everyone, and it's more important to have a name than to wait forever for the perfect name. 😄

[zufuliu]

What happens if the Notepad2.ini directs Notepad2 to use/save preferences in the user profile but there are no settings files in the user profile? Does Notepad2 create the files as needed in the proper location?

It behaviors as no INI files, INI from program folder is not used. however changes will be written into redirected INI path instead of program folder.
How about following approach: on first install, copy three ini files to one of three sub-folder in %USERPROFILE%. on upgrade leave them as is, INI file is no longer upgraded as it's hard to determine whether existing INI files in %USERPROFILE% folder has changed by user or not, this only impacts dark theme INI (which will add new styles), Notepad2.ini and metapath.ini contains mostly comments (new comments will be added into Settings2 section) should not be impacted.
In my past experiences, on Ubuntu after changed configuration inside /etc folder, on upgrade apt will prompt choices (leave user's copy, overwrite with package maintainer's copy, show diff) ; not sure whether Chocolatey has similar approach.

[teknowledgist]

The problem with the copy-into-%userprofile% approach is which profile(s)?

Say, AdminGuy installs this yet unnamed (hint, hint) Notepad variant and the Chocolatey script copies the INIs into AdminGuy's profile. When NormalDude logs back in, he won't have the INIs and neither will any new login users. Alternatively, the Chocolatey script copies the INIs into the default profile. When RegularGal logs in for the first time, she will have the settings, but neither AdminGuy nor NormalDude will have an INI since they already have profiles.

The benefit of redirecting the INI path from the source and to a "blank slate" is that everyone (existing profile or not) gets the same, default settings, and any preferences they set will be saved in their profile without risk of being removed/changed by an upgrade (or even uninstall/reinstall).

So, the question in my mind is: Are the default settings with no %userprofile% INI (assuming redirection) the same as the default INI? If not, that will make things confusing at best.

[zufuliu]

If I'm understood, this appears will need some changes in source code: when INI redirection is enabled (with Notepad2.ini=xxxxx like lines uncommented), if target INI file does not exist or is empty, then copy source INI file (e.g. from exe folder) to override target ini file.

[teknowledgist]

Whether the code needs changed or not depends on the answer to the question:

If the INI in the exe folder location has an uncommented line, Notepad2.ini=<filepath>, but there is no INI file in that location, will the program function properly and with the same default settings as defined in the INI (that is not being used)? Also, if a user makes a change to the default settings, will the program create a new INI in the <filepath> location?

If the answer is "yes" to both of those, then the code does not need changed.

If the answer is "no" to either, then I do think a code change would be necessary if you want this Notepad2 flavor to work "properly" for all users of a machine. The change you suggested would be one option.

IMHO, a better choice would be for all the settings contained in the default INI to be in-place without an INI. Only if a user makes a settings change in the GUI would the software create an INI. Maybe it could also test if the program/exe directory is writable by the current user ticket. If it is writable, then create the INI in that directory unless there is a setting to use a different path. If it is not writable, create the INI in the %userprofile% by default.

[zufuliu]

Both are yes, Notepad2 and metapath works perfectly without any INI files (which is the case when <filepath> doesn't exist). however Notepad2's dark mode (check the menu Scheme -> Style Theme -> Dark) works poorly for most schemes without a Notepad2 DarkTheme.ini file (normally in the same folder as <filepath> unless also redirected).

[teknowledgist]

Maybe the default Notepad2 DarkTheme.ini settings should be incorporated into the code so the file isn't necessary unless the user makes changes to them?

[zufuliu]

That seems complex, I see Notepad3 has more theme files, maybe "Notepad2 DarkTheme.ini" can be packaged/distributed using the same method?

[teknowledgist]

I guess? TBH, I didn't even realize Notepad3 had themes. That has never been of much interest to me in any app.

I think you could still use the test-for-modify-rights method. IOW: store all the default theme settings files in the application directory. If someone chooses a non-default theme, use it. If they want to adjust the theme, test if they have modify rights to the "themes" directory. If they do, go ahead and change that default file. If they don't have modify rights write either just the changes to an INI file within their userprofile or write the entire theme + any changes to their userprofile. That way, current users who just unzip to their desktop or documents folder could continue to work as they have and machines with it "installed" would work for multiple, unprivileged users.

[teknowledgist]

Any progress or further thinking on this? For my part, there are two "roadblocks":

1. There is no "official" new name.
2. The settings and themes are not machine-wide-friendly by default yet.

The latter can be (mostly) dealt with in the installation script, so to get a start on a Chocolatey package all I really need is the choice of name.

[zufuliu]

Sorry, but no progress. I think these INI files can be packaged same as Notepad3?

[enihcam]

any updates on this chocolatey package? @zufuliu

[zufuliu]

No progress. As I don't use these package managers, needs someone to work on, maybe similar to winget supporting.

[Mapaler]

winget 比 chocolately 好用，但是不支持Win7

[enihcam]

winget

winget is either lack of packages or out-of-date.

[teknowledgist]

Pull the trigger on (e.g. choose) a name (other than "Notepad2"), and I'll work on constructing a package.

[zufuliu]

Pull the trigger on (e.g. choose) a name (other than "Notepad2"), and I'll work on constructing a package.

How about Notepad2-zufuliu (as in readme) or zufuliu.notepad2 (winget)?

[teknowledgist]

I can use that, but it's rather long. The name poll has "Notepad2z" as the winner. Is there a reason you don't want to use that?

Whatever name you want, it would be best if this repo were renamed to match.

[zufuliu]

I don't want to change the binary names (Notepad2.exe and metapath.exe), which requires huge source changes (mostly renaming), and breaks end users with system integration enabled. How about -ng suffix for project name (Notepad2-ng and metapath-ng)?
https://github.com/zlib-ng
https://github.com/quickjs-ng

[teknowledgist]

I don't want to change the binary names (Notepad2.exe and metapath.exe), which requires huge source changes (mostly renaming), and breaks end users with system integration enabled. How about -ng suffix for project name (Notepad2-ng and metapath-ng)? https://github.com/zlib-ng https://github.com/quickjs-ng

That doesn't really answer my question (and you have no obligation to do so). Note that the naming discussion and poll were/are not about the binary name, but the project name. Lots of program binaries don't match the product/project name.

It's your baby, so if you prefer to name it "Notepad2-ng" rather than whatever the un-invested and fickle public think, that is your choice.

[zufuliu]

v24.07 is released with new program name Notepad4 and matepath, @teknowledgist please let me know when you have Chocolatey install instruction, so I can add it on release page.

[teknowledgist]

OK. I just submitted the notepad4 package to the public repository. You can view it at https://community.chocolatey.org/packages/notepad4 It can take a few weeks for the moderators to review and approve a new package, so it will not be normally available or discoverable until that time.

I made it an "embedded" package which makes it easier for Chocolatey users who may have more restricted networks, but that means it is limited to the English, "low-res" builds. It will be a lot more complicated to make the package work with all the other languages/options, so I'm not going to do that yet.

The package uncomments .ini filepaths in the INI files so the settings are not shared by all users, and it copies the INI files to the AppData location in default user. That will give future user account the default settings and the ability to change them. The package also copies the INI files to the installing user's AppData location (IF they don't already exist). If new releases aren't able to work with INI files used/modified by older releases, this could cause problems.

This is not my preferred method of making it both available to all users and "personalizeable" because any users who have existing profiles and are not the installing user will not be able to save changes to the settings because they do not have the INI files already in their profile.

Ideally, if the "base" INI files that live with the executable point to the user profile location (i.e. the .ini lines have been uncommented) and the path does not have any INI file present, the application would generate a default INI file either on startup, or at the point that any setting change that would normally write to the INI takes place. That feature should be easy to implement, and it means that any user could save their preferences even if they don't have an INI file in the expected location.

[zufuliu]

Thanks. it seems here are failure or false-positive for the package.

notepad4 has been flagged as part of automated virus scanning.

[zufuliu]

it seems here are failure or false-positive for the package.

I think it's false-positive by Antiy-AVL:
https://www.virustotal.com/gui/url/67cd4951f9068fa970de4cd124ede4b701a18ae0f65c2d5df12927a719e6d2da

https://www.virustotal.com/gui/url/6ba6e445b5fae96395669a78087be43f3a89362911d616065501366d16fb9a65

[teknowledgist]

Only 1 flag out of 69 is not really anything to worry about. The moderators generally don't start getting nervous until the number gets over 5.

[zufuliu]

The package is now approved, I added choco install notepad4 into https://github.com/zufuliu/notepad4/releases/tag/v24.07r5332.

@teknowledgist how about adding AVX2 build into the package? Most CPU (since 2013) and systems (64-bit Windows 7 SP1 or Windows Server 2008 R2 SP1) are capable to run AVX2 version.

[teknowledgist]

I can work on including more of the options, but I'd like a bit of additional info about them. For example:

• What is i18n? I see that it is "all above languages", but if it is only a tiny bit larger than all the other downloads, why not release only that one and make it easy for everyone?
• Similar question for HD. What happens if an HD version is run on a non-HD system? Can there just be one version with both HD and "low-res" options and the user can switch between them? Not two binaries, but can it be a view/settings option?
• Is there any way to automatically identify if a CPU/OS is AVX2 capable? If you know of a way (w/o third-party tools), I can include the test in the install instructions so users don't need to worry whether they are getting the "best" version for their system.

The ultimate goal here is to get the user the "best" version for their system without them needing to know a lot of details about their system. Users just want to easily install and uninstall and play with/select options after the fact. Making them think about what they can use/want ahead of time just makes them less likely to try it.

Thanks

[ZachBacon]

I can answer the i18n question and that has to do with localization, language etc.

[zufuliu]

1. i18n: contains localized DLL for languages (currently French, Italiano, Japanese, Chinese and Korean) other than English. I only use en version (single language for English), other people may like single exe & language version too.

2. HD: contains extra icon and image resources for screen DPI larger than 96 (100% scaling), to ensure toolbar etc. not blurry.

3. All Win11 non-ARM64 (Qualcomm) system supports AVX2, the Win32 API IsProcessorFeaturePresent() can be used to check AVX2.

[teknowledgist]

1. When I download i18n and run the binary on my English Windows, I see English menus and I see English as an option in the language selection sub-menu. I'm trying to understand why someone would want a single language version when the multi-language (i.e. i18n) should work just as well. If a user has a non-English Windows, does the i18n1 version still require them to select which language? IOW, might they have to find that language selection menu when they can't read the menus? That could be a problem. Would it be possible for the i18n build to ask which language to use (on first start only) using the native language names? That would make it possible to release only the multi-language versions and simplify download choices. Maybe I should adjust the package to embed the i18n build as it does appear to include English which the current package forces on users anyway?
2. I don't see any difference in the toolbars between HD and non-HD versions on my machine (but my monitors are only 1920x1080). Is there a setting in the application for selecting which toolbar size you want or is it automatic based on screen resolution? Either way would mean only the HD build would be needed. My suggestion would be to make it a setting choice because some folks might want really tiny or really big icons.
3. I have figured out how to test for AVX2 using PowerShell (which is not widely shared), so I can work on making the package "smart" to get/use the AVX2 version if it is available (and probably allow users to override that). If you can identify which processor feature needs to be present for the ARM builds to be used, I could probably add that as an option too. Expanding the binaries beyond basic x86/x64 in this way will mean the package can't be fully embedded which makes it a little less "portable" as a package.

Basically, what I'm trying to encourage here is to consolidate to a few builds as possible. If you can combine these options so that a single pair (x86/x64) of binaries can be used (the defacto standard for Chocolatey), it will make it a lot easier for everyone involved. If the single-language builds aren't necessary, you drop from 63 assets per release to 13. If you also combine HD and low-res, it drops to 10 (and the Chocolatey package doesn't need to mess with 5 of those -- code and FindInFiles).

Sorry if I'm being a PITA! 😄

[zufuliu]

1. i18n version auto select appreciate language (matches system UI) on startup, unless the non-System language menu is selected.
2. at 100% scaling (1920x1080), here is no difference, it only differences on large scaling (150% or higher). low-res version is built with NP2_ENABLE_HIDPI_IMAGE_RESOURCE=0, so some icons and images are excluded from exe.
3. only x64 supports AVX2 (Notepad4 AVX2 build is 64-bit only), if Chocolatey only support x86/x64 then there is no need to check Qualcomm ARM64 (PF_ARM_V8_INSTRUCTIONS_AVAILABLE can be used though). check CPU may be easier (CPU since 2013, all i3, i5, i7, i9).

[enihcam]

@teknowledgist Can we just default AVX2 version for x64? Older processors can pick notepad3 (notepad4 is too advanced to them. :)).

btw, thanks for your work on this!

[enihcam]

3. AVX2

@zufuliu Or can we enable AVX2 as default and standard to x64 architecture? That'd make your build work easier. Most of the Windows machines should have AVX2-built-in processors, since it was introduced in 2013 (no Windows machines can run for more than 10 years PLUS a need of using alternative notepad).

[zufuliu]

AVX2 as default and standard to x64 architecture?

No, but chocolatey (used by advanced users) package could just use AVX2 build.

[teknowledgist]

Although this is officially closed, I wanted to let anyone "watching" know that I have an update.

I apologize it took me so long to work through how to do it, but the Chocolatey package now has the AVX2 flavor embedded (instead of x64).

More importantly, it will check on the processor capabilities and if the two embedded installers (multi-language, Win32 and AVX2) won't work, it will instead download and install the best flavor. In addition users can chose any of the single-language flavors and/or to install Low Resolution (HD is the default). As far as I know, this is the only Chocolatey package that checks for AVX2/ARM and installs the appropriate build.

I have scripted the package updates, so it should be simple to keep up with any releases and all their flavors. Although the description on the community package will have to be manually updated if any additional single-language options come along in the future, the language install option should work automatically if the user knows the language code/abbreviation.

Let me know if you add any languages or remove the low-res option so I can change the description (and code if necessary). I don't normally check on release notes as I have too many other packages and the package update process is automated.

[zufuliu]

Thanks for maintain the Chocolatey package.

Let me know if you add any languages

de (German, Deutsch) and ru (Russian, Русский) will be included in next week's v24.11.

[zufuliu]

Although this is officially closed, I wanted to let anyone "watching" know that I have an update.

I created #914, you can post news here.