Color preferences overhaul

[bastiK]

Color name registration (Preferences.registerColor) and ColorPreference could do with some updates.

• It relies heavily on fragile string matching and several things are no longer working as intended.
• Color names are only registered at runtime for the current session, but the table shows all colors from the preference defaults. Now that JOSM remembers default preferences from the previous sessions, this leads to a mix of color names and raw preference keys in the GUI table.
• The table model relies on a Map from translated names to preference keys (error prone).

[bastiK]

In 12929/josm:

see #15410 - fix GUI table displays pref keys instead of registered and translated color names

[bastiK]

In 12942/josm:

see #15410 - better fix for color name display

[bastiK]

In 12943/josm:

see #15410 - do not attempt to translate preference key

[bastiK]

In 12944/josm:

see #15410 - better display of mappaint colors

[bastiK]

In 12945/josm:

see #15410 - fix display of custom layer color

[bastiK]

In 12946/josm:

see #15410 - fix deleting color entries; do not display unchanged layer colors (this gets excessive if user opens may gpx files over time)

[bastiK]

In 12947/josm:

see #15410 - set cell renderer only for 2nd column, not entire table

[bastiK]

In 12949/josm:

see #15410 - update test

[bastiK]

In 12950/josm:

see #15410 - add custom table model

[bastiK]

In 12952/josm:

see #15410 - don't map translated values to keys; locale sensitive sorting

[bastiK]

In 12953/josm:

see #15410 - highlight entries with modified color; fix "set to default"

[bastiK]

In 12954/josm:

see #15410 - better sorting

[bastiK]

How can you acknowledge a Checkstyle warning?

[Don-vip]

acknowledge? What do you mean?

[Don-vip]

In 12959/josm:

see #15410 - checkstyle

[bastiK]

Replying to Don-vip:

acknowledge? What do you mean?

Make the informed decision to ignore it. It's good to point out unnecessary public modifiers in interfaces, but in this case I would prefer to keep it.

[Don-vip]

It's possible by adding checkstyle comments // CHECKSTYLE.OFF: xxx and // CHECKSTYLE.ON: xxx (xxx being the check name) before and after the declaration. Or simply make the class public. Why do you want to keep a public constructor on a private class?

[bastiK]

It shows the intentions whether this method/constructor should be used from outside the inner class or not, even though this isn't enforced by the compiler. If you were to refactor the class and make it public, then you can simply keep the access modifier as is.

[Don-vip]

OK I can see if we can tune the checkstyle test to allow it.

[bastiK]

In 12982/josm:

remove old migration code (see #15410)

[bastiK]

In 12983/josm:

see #15410 - move cached() convenience method to super type

[bastiK]

In 12987/josm:

see #15410 - change preferences scheme for named colors - makes runtime color name registry obsolete

[bastiK]

In 12989/josm:

closes #15410 - update tests + minor fixes

[bastiK]

In 12990/josm:

see #15410 - update tests + minor fixes (2)

[Don-vip]

In 14152/josm:

see #15410, see #16604 - restore restart notification when mappaint colors are modified in preferences

[simon04]

Ticket #2973 has been marked as a duplicate of this ticket.