This topic contains 5 replies, has 2 voices, and was last updated by jason 2 months, 1 week ago.
8 October, 2018 at 11:02 pm #687
I just updated to 1.91 and while experimenting, I noticed the new language file overwrote my custom language file.
I’m curious, do specific settings have to be in the specific files, desktopinfo.ini or [language].ini?
I wonder if you were to read in a third file, from the same folder as DeskstopInfo.ini called MyDesktopInfo.ini, and if you were to read it last, if it would allow us to customize our settings without the worry of having them over-written?
You would never supply “MyDesktopInfo.ini” with your distribution, (although you could suuply “Sample_MyDesktopInfo.ini”) and since it would be read last, any variable created by our MyDesktopInfo.ini file would always take precedence over your default settings?
Example, if you supply “language=language\english.ini” as a default, and I added “language=language\french.ini” in “MyDesktopInfo.ini”, then whenever I download a new version of DesktopInfo, I would still see french, no matter what you set as default. Very much like apache and PHP read specific files last to allow static personalization.
9 October, 2018 at 6:49 am #688
Interesting thought. I know how annoying it is when putting the latest build on a machine with a custom config. It does look for specific items in either ini file, for example, language specific stuff only from the language files, item info only from the main ini file.
I don’t much like the idea of potentially having to read in the item config twice and then try to reconcile two versions but it bears thinking about.
- This reply was modified 2 months, 1 week ago by Glenn.
9 October, 2018 at 11:58 pm #690
I’m having second thoughts about the way I’ve set up the config/language stuff. I’m thinking I might have made things too complicated for the first time user. That and trying to avoid accidentally overwriting a custom config. The first thing you do when get the new version is start modifying it to suit your needs so the one I ship is never going to look like your version.
So I’m thinking of your idea of shipping a desktopinfo.sample.ini file.
When DTI runs, it looks for the regular desktopinfo.ini file.
If it finds it, it loads it and that’s all.
If it doesn’t find it, it looks for desktopinfo.sample.ini and loads that. In addition, it immediately copies that file to desktopinfo.ini.
Now the setup looks and acts as per normal.
I think the sample ini should contain all the english text and the other language stuff so that it is self contained. You would only use a language file to override the text for a different language. And I think they should be shipped as “.\sample-languages\*.ini”, again, to avoid overwriting custom files.
13 October, 2018 at 6:28 am #713
Your idea sounds very good. I like this solution better, because of the custom formatting issues.
Would DesktopInfo always look for desktopinfo.ini at startup? And behave as you described?
I ask because I can see myself deciding to observe all the changes you made from one version to another display on the screen (as opposed to the readme.txt)
Knowing how I think, I would rename desktopinfo.ini to _desktopinfo.ini and expect to see the sample brought in to service. 🙂
13 October, 2018 at 8:48 am #716
Yes, the idea is if the regular ini file is not there, the sample is copied over and used.
of course you can always use the /ini command line switch.
I’ve started implementing this and I’m much happier with the transparency of operation. I’ve got the language files nicely overriding the main ini file and I can select what things to override in a similar way to php as you described earlier.
13 October, 2018 at 2:34 pm #718