Easier to upgrade: Avoid overwriting DmdDevice.ini

[JockeJarre]

Is your feature request related to a problem? Please describe.
As an end user you are supposed to update DmdDevice.ini to match your installation.
Over time you have also saved a lot of positions for your dmdscreens. Each time you upgrade, you have to watch carefully to update all files but DmdDevice.ini

Having done this, it is always frustrating each upgrade because there are files in the zip file that can "destroy" your installation.

Describe the solution you'd like
Rename DmdDevice.ini to DmdDevice_template.ini in the zip file. Then it is only the first time a new user has to take caution (which has to be made anyway) to copy DmdDevice_template.ini to DmdDevice.ini and modify it.

Describe alternatives you've considered

1. As an option, when starting, it could bring a requester that the DmdDevice.ini file is missing.
2. Or if DmdDevice.ini cannot be found, that it automatically copies DmdDevice_template.ini into DmdDevice.ini

[JockeJarre]

@freezy is this something you want me to look into and provide a pull request for?

[freezy]

TBH I'm a bit divided on this one.

Basically, you're proposing a mechanism to protect users who don't read the documentation and have no clue what they're doing.

That's fine, as long as those who do read the doc aren't impacted. Now, with this template mechanism, we need to explain to users who read the docs what this is about. Why do we name it like that, and why does it get renamed/copied when you start the program.

We also need to explain to all users that they shouldn't update the template in order to change the config, but the .ini, but only if there's no .ini. This is not an insignificant complexity.

Additionally, the zip file is supposed to be the version for people who know what they're doing. For the others, there is the installer, which checks whether there is already an .ini file and doesn't overwrite it on re-installation.

Maybe a comment in the release notes to use the installer if you don't know what to do with the files would be a more pragmatic solution?

[JockeJarre]

I would rather argue that those who know what they are doing would be happy if they could unzip the file without the ini being overwritten each time. It is of course even worse if you forgot to take a backup...

So for power users I would rather get the template extracted and then merge in the new settings manually. As it is today I have unzip all files but one, then select the ini to extract it elsewhere or with a different name. It is many manual steps.

We can then skip the automated part completely. (Only the installer would automatically put in the ini)

[freezy]

Okay but if the "merge" is the problem, then there are other solutions. First of all, breaking BC with a new version happened once or maybe twice in the 8+ year long history of dmdext, and they were clearly communicated.

For new settings, they shouldn't be determined by manually eye-balling both the dmddevice.ini and the shipped (extracted) one. I can see that we weren't super transparent about that, but new settings should be in the release notes. If we do that (and we should!), merging becomes a non-issue.

About power users not being able to extract all but one file, I don't buy that. I would argue then they aren't power users. ;)

I would propose:

• Document new settings in the release notes so you can copy+paste them into your .ini file directly, without having to extract the shipped one.
• Also in the release notes, make it clear that only power users should download the .zip archive, and the DmdDevice.ini shouldn't be overriden.

My main issue is still that I don't want to explain to new users that they have to rename their config file and deal with users whose settings don't work because they didn't read the docs and thus didn't rename the config file.

[freezy]

Okay, after discussion with LoadedWeapon, we agreed on the following compromise:

• Add a banner to new releases (already done for the last release)
• Put the DmdDevice.ini into a sub folder in the ZIP file so it shouldn't conflict with existing ones.

That okay for you too, @JockeJarre?

[JockeJarre]

Sounds great!