Handle site palette configuration better

[leamas]

Is your feature request related to a problem?
Some users for example Swedes like me wants to use a site-specific chart palette. This is described in the user manual.

However, the method described means that this configuration is lost on an OpenCPN update. Not nice.

EDIT: Furthermore, on Debian/Ubuntu it means modifying files under /usr which makes the packaging system extremely upset for good reasons. Flatpak is immutable, so here it's just not possible. Overall, the Linux situation means that this could be seen as a bug rather than an enhancement.

Describe the solution you'd like
A user configured palette should not be affected by an OpenCPN update.

Describe alternatives you've considered
The core change would be that OpenCPN searched in some user and/or site path for the palette files before falling back to the palette which is part of the installation. Actual paths should not be a problem on any platform.

Additional context
Too late for 5.10

[Hakansv]

Can be complicated if the files in question are changed by an O update installation? Then any method has to walk through both versions and try to implement the changes in the user's file(s) and also detect what differences affect the SE settings and what's a O update change. But if so the need for future SE-palette updates are gone. :)

[leamas]

This is a classic problem. The simple approach is to merge upstream changes with the local ones. There are tools for that, including GUI ones like meld (it's basically the same problem as merging git branches.). That said, it can probably not be automated, and perhaps better done using some xml-aware merge tool if there are such beasts out there.

Anyway, if user uses a modified file it's her responsibility to maintain it. A change like this would just make sure that no user files are lost in an update.

[Hakansv]

Anyway, if user uses a modified file it's her responsibility to maintain it. A change like this would just make sure that no user files are lost in an update.

That's why the manual note "Save the extracted files for possible future O update".
Personally I have them in the /s57data folder but renamed to e.g. "chartsymbols_SE.xml" and they remains after updates.

[leamas]

Personally I have them in the /s57data folder but renamed to e.g. "chartsymbols_SE.xml" and they remains after updates.

You actually need three versions of the file to handle an update:

1. The previous OpenCPN version
2. Current OpenCPN version
3. Your own, modified version.

With these you can set up a 3-way merge. It's basically about applying the diff between 3) and 1) to 2). It will always be manual.

If we store 3) in another location where it also actually is used this one is OK. 1) and 2) can be maintained automatically by OpenCPN installation scripts.

Don't forget that modifying files under .../S57 is more or less impossible on Linux. While "possible" on Windows and MacOS it's still a bad practice. It's just that it's the only thing which works right now.

[Hakansv]

Yes, everything can be solved by logic if needed?
Also, yes, with Windows it's simply as usual. :)

[leamas]

Also, yes, with Windows it's simply as usual. :)

Not simple but broken. That the installation isn't write protected is a major flaw leading to this mess. ;)