Automatic update ssystem_minor.ini file

Stellarium / stellarium

Stellarium is a free GPL software which renders realistic skies in real time with OpenGL. It is available for Linux/Unix, Windows and macOS. With Stellarium, you really see what you can see with your eyes, binoculars or a small telescope.

https://stellarium.org

GNU General Public License v2.0

7.75k stars 820 forks source link

Automatic update ssystem_minor.ini file #3240

Open alex-w opened 1 year ago

alex-w commented 1 year ago

Speaking of updating: When installing a new version of Stellarium, ssystem_minor.ini will be kept, including old and possibly outdated data. Maybe add an update option at first program start (do we see if a new version has been installed? Yes, if config.ini:main/version mismatches!) to "Replace minor bodies data with default file? [Y/N/Never]". If yes, copy file from program location. If "Never", add another flag "main/restore_sso_defaults=false" to config.ini to suppress this dialog...

Originally posted by @gzotti in https://github.com/Stellarium/stellarium/issues/3230#issuecomment-1561168347

github-actions[bot] commented 1 year ago

Hello @alex-w!

Thank you for suggesting this feature.

10110111 commented 1 year ago

Why is the old file kept? If the data supposed to be edited by the user, this should instead be done in a user-specific directory, the data in which would override the data in the default file, which would be updated on Stellarium update.

gzotti commented 1 year ago

Misunderstanding. When you install a new version of Stellarium and run it, ssystem_minor.ini will only be copied to the user data dir if it does not exist there. This is intended, as you may have edited your version and added more comets or whatever. But if you install a new version of Stellarium and expect the data for Ceres or such to be updated, currently you get the old data file which may have outdated elements. Less experienced users may wonder why the outdated elements warning would appear for "even Ceres, right after they have installed the latest version".

10110111 commented 1 year ago

This is why I think it's a bad architecture. The old file should be retired, the default one should reside in the system directory, and the user's one (renamed from the old name to avoid interference) should just override (or add) the items that the user needs.

gzotti commented 1 year ago

I disagree. If I have configured my own file, with more or less objects, I don't want that this file gets auto-retired on upgrade. (I can also configure the ssystem_major.ini file and e.g. remove moons of Uranus/Neptune if I use only my solar-/battery-powered slow system and binoculars and don't need them. ) User should have a chance to decide about retirement, also getting rid of outdated objects when not interested in views from last month. First launch after upgrade sounds reasonable. The luxury variant of this would be "upgrade existing". This would import/overwrite data from the new default file.

One thing could however be added: Several element sets per object, with different epochs. This would make things increasingly complicated, though...

10110111 commented 1 year ago

OK, then let the objects in the current user-specific file override those of the system one (per-property of each object, rather than per-object) instead of using only the user-specific file.

Then, if you really want to be able to let the user-specific file remove some elements from the system one, add an optional setting like 3juno/remove=true. Or to have the file start from scratch (so that objects newly-added in an upgrade don't suddenly appear), this could be done with an entry like settings/from_scratch=true.

alex-w commented 1 year ago