[Feature Request] - change extension of Themes file about fwdataviz HOT 4 CLOSED

@artie-finkelstein,thank you for your feedback.

1. When the file types and themes are configured inside the plugin's purpose-built editors, the plugin saves backups of their previous versions in the AppData\Roaming\Notepad++\plugins\Config\FWDataViz\Backup or the NPP_Portable_path\plugins\Config\FWDataViz\Backup common folder. To segregate the file type and themes config files in the backup reload File Open dialog, I had initially opted for them to be with different extensions.
2. At my work's Unix servers, we extensively use .dat files to setup custom environment variables, to provide a list of folders/files/filters/templates/user accounts to be processed by various shell scripts/Perl scripts. And, all these .dat files are in plain text. On the Windows side, I have seen a few games using plain-text .dat files.
3. Although the keys in the Themes config file are in plain text, their values are all in hex code. At least for those not fluent with HTML/CSS color values, it can be argued that this is a binary file.
4. For anyone using Windows File Explorer alternatives, like Xplorer2 or XYPlorer or Multi Commander, configuring them to open files with any extension in NPP is fairly straightforward.

With all that being said, I still find your request reasonable and doable. Moreover, w.r.t. my item no. 1 above, I now find the plugin's config dialog screens to be stable enough to not crash if a user chooses the wrong config file during the backup reloads.

I have implemented your feature request in the 2.1.1.0 Release. Please try it out.

• During the very first load, the plugin will automatically rename the themes config file from Themes.dat to Themes.ini.
• In the themes backup reload File Open dialog, I have provided separate *.ini and *.dat file filters. The latter is for users who may want to view backup files saved with the .dat extension.

from fwdataviz.

from fwdataviz.

from fwdataviz.

@artie-finkelstein, Thank you for closing this issue and taking the time for this conversation.

[The numbers in my response below refer to the paragraph numbers in your post.]

1a: I have three different potential ways to quickly view a file. Firstly, I exclusively use Xplorer2 instead of Windows File Explorer. In Xplorer2, I just use the F4 key to open one or more selected files in NPP. (Even in the WinSCP program that I use for SFTPing to Unix servers, the same F4 key opens files -- both local & remote -- in NPP.) Secondly, the double click action still opens the file in whatever is its default handler. Thirdly, I have also configured the Send to menu in my PC by placing links to various common file handlers in the %APPDATA%\Microsoft\Windows\SendTo folder. I just right click and use the Send to option to choose a different viewer for a file. An example handler for this 3rd way is Sandboxie for opening unfamiliar but intriguing exe files.

1b: After reading your post, I put out the 2.1.1.1 Release today. In this latest version, the config files are backed up using the CopyFile Windows API instead of the earlier MoveFile Windows API. This will enable potential use for hardlinks with the config files. Just this single API call on line #309 was changed in this file.

In Unix, when you use cp to copy a file, the copied file will have the then current timestamp instead of the source file timestamp; and, cp -p option needs to be used for preserving timestamps. Influenced by this, I mistakenly assumed that the Windows CopyFile too will alter the file timestamp, and opted to use MoveFile instead. It turns out, CopyFile does preserve the source file's timestamp. So, replacing MoveFile with CopyFile has still left in place my intention of preserving the original timestamps on the backed up config files.

2: When you are halfway in building a fairly large application, you tend to be conservative, and will opt for as many safeguards as possible. So, I had opted to use the File Open dialog's file filter option to segregate the config files with different extensions. I am referring to this dropdown control in the File Open dialog:

But now that the plugin is fully built, I am able to successfully test that loading the wrong config file into either of those editors will not crash them. So, segregating the config files by their extensions does not make much sense any more.

By the way, in the 2.1.1.1 Release, I also have a fix for an issue that had been bothering me for the past several weeks. Please see the first item in the release notes. Definitely, I must not have been the only one to have noticed it. If it had been reported as an issue here, I would have probably fixed it sooner.

from fwdataviz.