1. https://code.hampel-soft.com/open-source/dqmh/hse-application-template/-/issues/158: Config structure 2. https://code.hampel-soft.com/open-source/dqmh/hse-application-template/-/issues/137: Build specs 3. https://code.hampel-soft.com/open-source/dqmh/hse-application-template/-/issues/160: Wizard 4. https://code.hampel-soft.com/open-source/dqmh/hse-application-template/-/issues/159: Installation 5. https://code.hampel-soft.com/open-source/dqmh/hse-application-template/-/issues/162: Setup/Init ---- **Prerequisites** * https://dokuwiki.hampel-soft.com/code/common/project-structure * https://dokuwiki.hampel-soft.com/code/common/deployment-structure * all requirements here shall also apply to the DATA folder where applicable * these ideas affect the `hse-libraries` and `hse-application-template` repos **What problems do we want to solve?** 1. Our HSE Application Template shall work on a given set of configuration data * (we already have that with our CONFIG folder and UNIT subfolders) 2. We shall be able to provide user-defined locations for the CONFIG folder * (we already have that with the application-specific exe.ini) 3. First-time installation on an enduser PC shall create all necessary files (config folders, config.ini, unit_default...) * alternative: create files not during installation but during first run 5. Update installation on an enduser PC shall update the default settings but not overwrite any user-specific (config.ini and Unit_xyz) files **Notes** Unit folders used to be helpful with * running the same application on different computers and maintaining all configuration in one place (repo) * running the same application with different configuration sets on the same computer * maintaining development/developer configuration and enduser/testsystem configuration