Custom color dialog produces bogus color codes

Boothy99 commented 1 month ago

Description

When attempting to change the group default color in "My Favourites", the color is not saving for any group if selecting a "Custom" color (EDITED.....) + Transparency slider to reduce opaqueness

Steps to reproduce

Open My Places / My Favourites, Select menu options for a group & choose.. Change default appearance, Produce a custom colour + decrease opacity & select it (or any previous custom semi-transparent colour), Apply to existing, Check colour changed (yes) Fully close OsmAnd after waiting a while for changes to register (remove from background apps) Re-open OsmAnd - the group colour has reverted to a default yellow.

Actual result

As above, on re-opening OsmAnd - the group colour has reverted to a yellow.

Expected result

On re-opening OsmAnd - the group colour should remain as selected custom colour.

Your Environment (required)

Device : oriole Brand : google Manufacturer : Google Model : Pixel 6 Product : oriole Build : AP2A.240905.003.F1 Version : 14 App Version : OsmAnd+ Apk Version : 4.9.0 4900

Also occurs on Samsung Galaxy Tab S4 ... Device : gts4lwifi Brand : samsung Manufacturer : samsung Model : SM-T830 Product : gts4lwifixx Build : QP1A.190711.020.T830XXU5CVG2 Version : 10 App Version : OsmAnd+ Apk Version : 4.9.0 4900

Boothy99 commented 1 month ago

I've opened a separate report regarding Export / Import corruption here - https://github.com/osmandapp/OsmAnd/issues/20805#issue-2516609899

UPDATE ; Above issue "Export / Import corruption" Resolved & closed.

yuriiurshuliak commented 1 month ago

The bug has been reproduced. To replicate, change the default appearance for the favorites group by selecting a different color, icon, and shape. Click "Apply to existing" and confirm that the appearance has been updated. Afterward, completely close the app, reopen it, and check the favorites group.

As a result, you will see that the default appearance has reverted to its original colors and shapes, despite the changes you previously applied.

OsmAnd~ 4.9.0#3157m, released: 2024-09-10

https://github.com/user-attachments/assets/d8371462-8c95-4568-aa25-e71d39d44f94

Boothy99 commented 1 month ago

Thanks for confirming the bug can be reproduced @yuriiurshuliak 👍👌 I also see that you received a "Add favourites / import" screen on initially opening My Favourites. I've seen that too. Cheers

sonora commented 1 month ago

@yuriiurshuliak, @Boothy99

Watching the video, perhaps this is a simple timing issue, killing the app too early after the change is applied, but not yet written:

Can you please test like this, because I cannot reproduce with this procedure:

Change the default appearance for a group
Hit "Save" and "Apply to existing"
Stay on this screen or return to the map screen, but give it a minute or so for the app to finish writing the appearance changes to the backup file (I believe that the points are written to the internal database rather quickly, but the point/group appearance may only be kept in the backup files, which is comparatively slow).
Now kill the app and restart it.

In my testing the appearance is correctly reflected, no matter what type color I had set it to?

The app briefly showing "No Favorites yet" on the screen seems to indicate that it has no backup files (yet), then restores the points from its internal database (which I think may not contain no appearance information).

Boothy99 commented 1 month ago

@yuriiurshuliak - thanks again for testing. I think I've narrowed things down (& edited the title + method to reproduce).

What I missed out was the fact that for certain categories of POI, I'd chosen a Custom colour AND reduced it's opacity. If I select any of the default colours, then I saw there's no issue in it getting saved. As soon as I make a custom colour + use the transparency slider (~50%) ... THEN the colour will not save - even after I leave OsmAnd open for 5 to 10 minutes. Any standard default colour (full opacity) is saved without issue.

So, for me at least ... it seems that reducing the opacity appears to be the culprit. Any custom colour I choose is remembered, so long as I don't reduce it's opacity. Any thoughts and comments appreciated. Thanks for testing @yuriiurshuliak 👍👌

sonora commented 1 month ago

Good observation!

It looks like setting high opacities (>50%) produces bogus color codes like color="#-77010000 in the gpx file, both when using the slider or a textual input. We probably use a signed integer and hence have a roll-over to negative values somehow when converting 8-digit hex colors.

Boothy99 commented 1 month ago

Sending thanks over to yet again tonight, @sonora 😁 Do I get my bonus points back for zeroing in on the issue after losing some on the Export / Import non-issue ? 😂 Cheers for changing the title to a more technical version 👌

gpsvisualizer commented 1 month ago

I discovered this opacity issue today and am glad to see someone's aware of it. It applies both to individual favorites AND to the default appearance of a favorites group: everything's fine while the app is open, but a not-fully-opaque color gets turned into a "negative" hex code in the GPX files.

Here's some more details: in "favoritesbak2024-09-06…", one of my saved points has a color of #aaff00e7. The same point in "favoritesbak2024-09-08…" has been changed to #-5500ff19. (Sure enough, one is the negative counterpart of the other, in hexadecimal gobbledegook.) So something changed between September 6 and September 8 to cause the problem.

Boothy99 commented 1 month ago

Thanks for your comments & confirming, @gpsvisualizer 👍

sonora commented 1 month ago

Very likely the bug was there before. And last week some bugs were fixed which finally corrected OsmAnd looking at these color tags, so now we start seeing this glitch... ;)

sonora commented 1 month ago

We have a lot of places (room for simplification) converting color to string, all slightly different: https://github.com/osmandapp/OsmAnd/blob/69047bd65e28ee1d63d97f5298603c1563fb9fe6/OsmAnd/src/net/osmand/plus/helpers/ColorDialogs.java#L156 https://github.com/osmandapp/OsmAnd/blob/69047bd65e28ee1d63d97f5298603c1563fb9fe6/OsmAnd-java/src/main/java/net/osmand/util/Algorithms.java#L1065 https://github.com/osmandapp/OsmAnd/blob/69047bd65e28ee1d63d97f5298603c1563fb9fe6/OsmAnd-java/src/main/java/net/osmand/render/RenderingRulesStorage.java#L203 https://github.com/osmandapp/OsmAnd/blob/cb74d8cb7fce574bf7bdde040b3e0ac510bc45ec/OsmAnd-shared/src/commonMain/kotlin/net/osmand/shared/util/KAlgorithms.kt#L95

(We also have multiple places parsing color, more room for optimization.)

Somewhere we seem to use a method interpreting an integer as a signed one, and producing a signed "-" hex representation for negatives.

sonora commented 1 month ago

This PR fixes it: https://github.com/osmandapp/OsmAnd/pull/20825.

Optimization may still be done consolidating all the various colorToString and parseColor methods.

Boothy99 commented 1 month ago

Appreciate you getting on to this so quickly 👌

Boothy99 commented 4 days ago

A quick thanks to @sonora and team for fixing this 👍👌 Updated Beta to OsmAnd+ 4.9.2, (released: 2024-10-25) and translucency of icons works perfectly again, cheers.

osmandapp / OsmAnd