Modify

Opened 8 years ago

Closed 7 years ago

#12522 closed enhancement (wontfix)

Advanced preferences: display default entries consistently

Reported by: bastiK Owned by: team
Priority: normal Milestone: 16.02
Component: Core Version:
Keywords: Cc:

Description (last modified by bastiK)

In the advanced preference dialog, we do not show keys and default values for all settings that exist in the software. Instead we fill the list at runtime, whenever the value of a setting is requested in the code.

I noticed this is irritating and users often don't understand this concept.

It would be better, if the list of advanced preferences would consistently show all (or nearly all) available entries.

Proposed solutions:

  1. Central registry: Basically convert all Main.pref.get(...) calls to StringProperty and put those properties in a class that is loaded early.
  2. When JOSM exits, write all known defaults to a cache file (~/.josm/cache/default_preferences.xml) and load these entries back at next start.

edit:

  1. Static code analysis: Scrape the JOSM source code (or byte code) and collect all preference keys + default values. Then distribute this list in the .jar file and load at runtime.

Attachments (3)

save_default_settings.patch (17.1 KB ) - added by bastiK 8 years ago.
static_code_analysis-einstein_collector.patch (27.8 KB ) - added by bastiK 7 years ago.
static_code_analysis-einstein_collector.2.patch (31.7 KB ) - added by bastiK 7 years ago.

Download all attachments as: .zip

Change History (16)

by bastiK, 8 years ago

Attachment: save_default_settings.patch added

comment:1 by bastiK, 8 years ago

Attached is a patch for solution (b).

comment:2 by bastiK, 8 years ago

Resolution: fixed
Status: newclosed

In 9821/josm:

fixed #12522 - Advanced preferences: display default entries consistently

Saves default preference entries to a cache file (cache/default_preferences.xml), so the list of advanced preferences is filled with all known default values consistently from the start and not gradually as you use different features during a session.

comment:3 by Klumbumbus, 8 years ago

Milestone: 16.02

comment:4 by skyper, 7 years ago

Resolution: fixed
Status: closedreopened

Does not work:

  1. start JOSM without existing preference direction
  2. open preferences
  3. look for properties.recently-added-tags
URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-10-19 17:30:15 +0200 (Wed, 19 Oct 2016)
Build-Date:2016-10-20 01:37:11
Revision:11148
Relative:URL: ^/trunk

Identification: JOSM/1.5 (11148 en) Linux Debian GNU/Linux 8.6 (jessie)
Memory Usage: 527 MB / 882 MB (212 MB allocated, but free)
Java version: 1.8.0_102-8u102-b14.1-1~bpo8+1-b14, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-8-jre:amd64-8u102-b14.1-1~bpo8+1
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-9
Program arguments: [--language=en]
Dataset consistency test: No problems found

Plugins:
+ Mapillary (v1.3.1)
+ apache-commons (32699)
+ apache-http (32699)
+ imagery_offset_db (32796)
+ reverter (32796)
+ tag2link (32941)
+ undelete (32699)
+ utilsplugin2 (32815)
+ wikipedia (33017)

Last errors/warnings:
- W: java.net.SocketTimeoutException: Read timed out
- E: java.net.SocketTimeoutException: Read timed out
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.mapillary.gui.MapillaryChangesetDialog$SubmitAction@34da22e6
- W: Unable to get color from '' for color preference 'extrude.main.line'
- W: Unable to get color from '' for color preference 'improve.way.accuracy.helper.line'
- W: Unable to get color from '' for color preference 'make.parallel.helper.line'

comment:5 by Klumbumbus, 7 years ago

(starting point was ticket:13717#comment:6)

Also there is no default_preferences.xml file in my cache folder.

comment:6 by bastiK, 7 years ago

Resolution: fixed
Status: reopenedclosed

This works as intended:

  • For advanced properties to show up in the list, they have to be "requested" at least once. In this case you have to add a tag once to register the property properties.recently-added-tags.
  • The improvement in [9821] is that these entries will be remembered when JOSM is closed and reopened.
  • The cache/default_preferences.xml will be created when JOSM exits.

This is not perfect, but the next best solution (a) is much more involved.

comment:7 by Klumbumbus, 7 years ago

Thanks for the explanation. Well, I still can't find the cache/default_preferences.xml file but JOSM correctly registers the preference key after it was requested and also remembers it after restart. So it works as you describe.

comment:8 by bastiK, 7 years ago

Description: modified (diff)
Resolution: fixed
Status: closedreopened

comment:9 by bastiK, 7 years ago

I've experimented a bit with static code analysis and found another (partial) solution to this problem. The patch uses the INRIA Spoon library to extract preference keys from the JOSM source code. It even evaluates simple expressions like MyClass.PREFIX + ".setting". It finds most of the static keys, but not those that are constructed programmatically at runtime.

To run the patch, you need the file spoon-core-5.5.0-jar-with-dependencies.jar in tools.

I can see a whole lot of other uses for this kind of analysis: Most obvious would be collection of translatable strings. But as the current Perl extractor seems to be working fine, there is no reason to touch a running system. Then it should be fairly easy to code custom coding style checks, complementing the systems we already have in place (E.g. "Curly brackets after if, except for return, break and throw"). You could compile a custom Javadoc coverage report that raises a test error whenever is top-level public class is undocumented.

comment:10 by stoecker, 7 years ago

It was a design decision to have free preferences handling compared e.g. to a registration module, where preferences must be registered. I appreciate the work you did with the static code analysis, but please don't add the result file to JOSM distribution version. We can use this for tests and alike, but users of the "expert settings" should be expert enough to understand that an option must be used once before it's available. The caching is enough.

All the important options can always be reached in the configuration section independ from their first use. Expert options are by definition not important.

in reply to:  10 ; comment:11 by bastiK, 7 years ago

Replying to stoecker:

It was a design decision to have free preferences handling compared e.g. to a registration module, where preferences must be registered.

This design decision is based on the convenience for the developers, i.e. there is very little overhead or boilerplate code to convert a constant into a configuration option. From the user perspective, there is no advantage to this and a central registry would be preferable.

[...] users of the "expert settings" should be expert enough to understand that an option must be used once before it's available.

From what I have seen on the forums, etc., this is not the case. It is more common to expect that all existing options are listed.

All the important options can always be reached in the configuration section independ from their first use. Expert options are by definition not important.

One use case are Einstein flags that unlock new experimental features. Even not so tech-savvy users should be able to enable these and help with testing.

The change is clearly an improvement, admittedly a fairly minor one and needs heavy artillery to get there. What are your objections to the patch, other than "it isn't needed"?

in reply to:  11 comment:12 by stoecker, 7 years ago

[...] users of the "expert settings" should be expert enough to understand that an option must be used once before it's available.

From what I have seen on the forums, etc., this is not the case. It is more common to expect that all existing options are listed.

When in the forums users are discussing about Einstein prefs without knowing the limits, then there is something seriously wrong.

If options are discussed on larger scale in forums, then a GUI for these preferences is missing. I personally nearly never use the Einstein preferences except for development.

All the important options can always be reached in the configuration section independ from their first use. Expert options are by definition not important.

One use case are Einstein flags that unlock new experimental features. Even not so tech-savvy users should be able to enable these and help with testing.

No. They should not.

The change is clearly an improvement, admittedly a fairly minor one and needs heavy artillery to get there. What are your objections to the patch, other than "it isn't needed"?

It is again one of the many steps wasting space without a benefit for normal users. Like most actively developed software JOSM has a bloat problem. This solution adds bloat without a measurable positive effect. The existing cache already fulfills the requirements.

comment:13 by bastiK, 7 years ago

Resolution: wontfix
Status: reopenedclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.