update of the loolwsd.xml file inconsistent?
-
Hello,
I have noticed that on my different the loolwsd.xml had been updated at different time, one 2 months ago, another 11 months ago, another 12 months. I noticed it because on one of them I don't have the so called Cool UI (i.e. notebook) bar. Not a problem as I can probably just update the file manually if I need to and I also quite the classic bar anyway but it seemed an odd behaviour for the config file not being in sync (at least in terms of options) between the different instances. E.g. the one 11 month ago don;t have the <user_interface><mode> option at all or the version header.
So not a big deal but thought it was worth pointing out.
-
This is a good point. The reason however is, that the default config file, which is set in place on app installation, changes upstream and thus depending on the time the app gets installed, the instance will have a different default. An app update does not migrate or update the config file, since it is hard to figure out what was changed by the user manually.
Not sure how this could be currently improved. I guess we would need some way to provide a UI during update asking what to do with the config files, but that might be quite involved and possibly just adds confusion.
-
This is a good point. The reason however is, that the default config file, which is set in place on app installation, changes upstream and thus depending on the time the app gets installed, the instance will have a different default. An app update does not migrate or update the config file, since it is hard to figure out what was changed by the user manually.
Not sure how this could be currently improved. I guess we would need some way to provide a UI during update asking what to do with the config files, but that might be quite involved and possibly just adds confusion.
@nebulon Oh yes, I see what you mean, tricky. And I agree, probably best to keep the current behaviour to avoid confusion. Maybe just adding something about it in the doc for that app would be good so people know they might not be running the latest version.
-
This is a good point. The reason however is, that the default config file, which is set in place on app installation, changes upstream and thus depending on the time the app gets installed, the instance will have a different default. An app update does not migrate or update the config file, since it is hard to figure out what was changed by the user manually.
Not sure how this could be currently improved. I guess we would need some way to provide a UI during update asking what to do with the config files, but that might be quite involved and possibly just adds confusion.
-
@nebulon Why not just keep a script that replaces known variables and their values that are DIFFERENT from upstream for the Cloudron package? (sed/awk)
Distros do this all the time.
@robi we usually do this also for other packages. In this case there are no Cloudron specific values in this file, but if there are changes then only user customizations and one secret (also user-set).
Given that in this case for example a default option has changed, the notebook bar, it is unclear to me what and how to merge the config files.
