Opened 7 years ago

Last modified 6 years ago

#16869 new enhancement

Unify preferences API — at Initial Version

Reported by: michael2402 Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: hack-weekend-2018-10 preferences Cc:

Description

This is just a WIP progress

The goal of our preferences should be to not depend on any other part of JOSM and should be as lightweight as possible.

Current way of accessing preferences is e.g.:

  • Config.getPref().getBoolean
  • new BooleanProperty().get()

We currently have a preference system that has many options to represent values.
Ideas would be:

  • Drop the different settings types (list / map / list list) because they cover special cases.
  • Provide a common way to convert all preference type. For each type we define

A serializer that converts the java value to a string
A deserializer for the other way around
A validation mechanism.

  • Migrate the old list/map preferences to be simple strings.
  • Drop the different setting access classes, provide a common way to register / access settings.

Alternative goal:

  • Use some sort of classpath scanning to detect all settings that are defined on the classpath. Because we currently have the problem that available settings are not known to JOSM.

Alternatives are to change the preference format to JSON (would require big dependencies but automated serialization / deserialization)

Change History (0)

Note: See TracTickets for help on using tickets.