[patch needs rework] layer color resets to default when renaming layer

[kolesar]

What steps will reproduce the problem?

1. Load some GPX data from OSM server.
2. Right-click layer "Downloaded GPX Data" in the layer manager.
3. Customize color of layer. (If you have a custom track trawing option, set track and point coloring option to single color.)
4. Rename the layer (or save to GPX file with a different name).
5. Zoom or pan map.

What is the expected result?

Color remains the same.

What happens instead?

Color is set to default (or another color saved in a previous session).

Please provide any additional information below. Attach a screenshot if possible.

Custom layer colors are stored in preferences with a key that contains the name of layer. When layer is renamed or saved on a different name, map paint does not find the setting.

Applying color when a file is reopened is a good idea. Color information should not be saved a preference entry using the file name without full path. This causes WTF experience in the user. I have found this behaviour a problem when I opened several GPX files and some of them were coloured differently.

Name-based colouring is also bad when layers are not renamed or saved as a new file. If you open more than one GPX layers having the same file name and set color to one of them, new color will be applied to all of them.

Color should be stored at layer properties and saved to the file itself. For backwards compatibility saving color to preferences should be an option but not default.

Attached patch that saves color into GPX files and reads back on opening. One color for tracks, one for marker layer. They are handled together on load and save.

Compatibility switch is called dialog.layer.use-pref-layer-name, default is off. If someone needs colors saved to preferences, can switch it on. Original rename bug does not affect compatibiliy mode because color stored in layer has precedence.

[bastiK]

Note that there are more settings that can be customized for gpx layer drawing (see CustomizeDrawingAction). For consistency, they should all be handled the same way.

A main use of the "customize color" feature are gpx files recorded during a survey with a GPS tracker. Typically you have several files collected over multiple sessions and like to display them in different colors. Your patch doesn't work for this use case, since these gpx files are just opened and never saved.

When saving a gpx layer as part of a session, this metadata should really be included in the session file. It would allow the user to make the color and other settings permanent and it works both for downloaded and recorded gpx data.

[kolesar]

Replying to bastiK:

Note that there are more settings that can be customized for gpx layer drawing (see CustomizeDrawingAction). For consistency, they should all be handled the same way.

I have started to implement saving settings to session. Now I have more questions than before.

CustomizeDrawing is not so clean as layer color. Color is an object that can be null that means it is not overridden at layer level, global settings should be used. CustomizeDrawing has several options, some of them can be set to Use global settings but the rest are boolean, int or double that always have a value. It would be simple to change them to Boolean, Integer or Double objects that can be null but GUI and session save/load should reflect this. That's where important questions come into view.

Do we think about global layer settings as a template for new layers? Or are they live settings to layers that do not override them? Current implementation mixes these concepts.

Concept template: all layers have individual settings that are filled with global settings at creation time. These can be set later, but global settings do not affect these settings.

Concept override: new layers do not have individual settings unless they are set explicitly later. Settings have not been overridden use global values.

JOSM currently uses a mixed model. Starts with override model but when track drawing was customized on a layer, that layer follows the template model. Global settings do not apply anymore, except some settings that can be set to follow globals. When changing a setting to layers, all settings of dialog are replaced on all layers, possibly overwriting existing different settings.

Let's see an example. I have two GPX layers. I set width to 2 at one of the layers, 3 to the other. Later I set coloring to velocity for the two layers. All layers will have the same width, according to the first layer in list where settings are read from to the dialog. I think it's annoying.

Another problem of current implementation that mixes "local settings override globals" with "you can choose to follow global settings". There is an odd-one-out setting: Smooth GPX graphics (antialiasing) that looks like a local (override) setting but it is a global setting. If you change it for a GPX layer, all others change as well.

If we think in override model, should CustomizeDrawing keep track each individual setting if it overrides global setting? For example: [ ] Draw Direction Arrows can be set to Yes or No. There is no third option meaning Use global settings like at Draw lines between GPS points. I have implemented a TristateCheckBox class that allows that third option but that does not solve all problems. There are numeric fields like Drawing width of GPX lines. How can user tell JOSM to use global settings here without override?

• Dialog could have [x] Use global settings checkboxes for each individual settings. It would be clear what is overridden but it's compliated to use, one more click to disable this before setting something to enable local setting.

• Dialog can determine what was overridden by comparing values with global settings. Different values will be overridden settings, equal values will be stored as null in layer settings to use global settings. If user modifies global settings later, non-overridden settings follow global settings. Problems start when user a value locally to B, later changes global setting A to B. In this case setting will be B both at global and local level, but it's not clear if B is an override value or not. When saving to session or applying settings to multiple layers at a time it's important to know what was overridden value and what not (see later).

• Dialog saves all settings to layer, later changes in global settings do not apply to customized layers. This is the current behaviour, except the two radio buttons where there is a choice to (o) Use global settings.

Another question: which settings should be saved to session for each layers?

• Overridden settings only.
• All settings.
• All settings, overriden settings marked as overridden.

To answer this question, let's think about what do we expect when we load this session later. If all preferences kept unmodified, all layers should look the same like when was saved to session. But what should happen if some settings were changed meantime, for example draw width was increased?

I think it should work similar to the way if we did not save to session and load it back. If a setting was not overridden in a layer, this should follow default setting.

Session file should store viewport and layer state as these are the main XML tags in session file. But what are these settings in detail? Viewport center and zoom only. Projection is not stored in session that can be problem with imagery layers that do not support currently selected projection. Layers settings that can be changed in layer dialog. There is a bug: recently introduced gamma setting is not stored.

Side notes:

• JOSM calls traces as GPX lines. This is not a good practice. GPS traces can be imported not only from GPX formats (see NMEA), in the future I hope there could be even more supported formats, I plan to use GPSBabel as importer and exporter. Therefore I suggest to name them traces (as OSM calls them) or tracks (as most GPS applications call them) or something similar.

• There are Annoying Capitalized Words on GUI, for example Draw Direction Arrows. This is not used constistently, I hope these can be lowercased to Draw direction arrows.

• Custom drawing settings are stored in preferences using layer name that can be changed by rename or save as a new filename. This means all problems mentioned with layer color apply to customize drawing as well. This makes JOSM unavailable to transfer all session data between computers.

Suggested solution:

The template method is much simpler to understand and to implement as well. I would simplify settings dialog by removing "Use global settings" exceptions. There could be a new button Load global settings at bottom of dialog that replaces all settings with global ones. In this case user can see immediately what are those global settings and can customize them for selected layers.

The user should be able to apply settings selectively. The question is: which settings and which layers? I suggest the following settings to preferences page, controls with default options, radio group is disabled if checkbox above is unchecked:

    [ ] Apply changes to all existing layers
        (o) Apply modified settings only
        ( ) Apply all settings

At CustomizeDrawing dialog called for one or more layers:

    [ ] Apply changes to default setting for new layers
    [ ] Apply changes to all existing layers
        (o) Apply modified settings only
        ( ) Apply all settings

Customize dialog should display mixed state controls for settings that are different among selected layers when multiple layers are selected.

Session file should not contain all individual settings by default. I suggest to save only values different from global settings. For example, opacity is currently saved this way. It is written only if is not equal to 100%. For convenience an option could force saving all settings into session file:

    (o) Save customized layer options only
    ( ) Save all layer options, including default values

What do you think?

[bastiK]

Replying to kolesar:

Replying to bastiK:

Note that there are more settings that can be customized for gpx layer drawing (see CustomizeDrawingAction). For consistency, they should all be handled the same way.

I have started to implement saving settings to session. Now I have more questions than before.

[...]

Let's see an example. I have two GPX layers. I set width to 2 at one of the layers, 3 to the other. Later I set coloring to velocity for the two layers. All layers will have the same width, according to the first layer in list where settings are read from to the dialog. I think it's annoying.

Cannot reproduce, unless both layers have the same name.

Another problem of current implementation that mixes "local settings override globals" with "you can choose to follow global settings". There is an odd-one-out setting: Smooth GPX graphics (antialiasing) that looks like a local (override) setting but it is a global setting. If you change it for a GPX layer, all others change as well.

This should be changed to work like the other track drawing settings.

If we think in override model, should CustomizeDrawing keep track each individual setting if it overrides global setting? For example: [ ] Draw Direction Arrows can be set to Yes or No. There is no third option meaning Use global settings like at Draw lines between GPS points. I have implemented a TristateCheckBox class that allows that third option but that does not solve all problems. There are numeric fields like Drawing width of GPX lines. How can user tell JOSM to use global settings here without override?

• Dialog could have [x] Use global settings checkboxes for each individual settings. It would be clear what is overridden but it's compliated to use, one more click to disable this before setting something to enable local setting.

I think a "use global" option for each individual setting is impractical and awkward.

• Dialog can determine what was overridden by comparing values with global settings. Different values will be overridden settings, equal values will be stored as null in layer settings to use global settings. If user modifies global settings later, non-overridden settings follow global settings. Problems start when user a value locally to B, later changes global setting A to B. In this case setting will be B both at global and local level, but it's not clear if B is an override value or not. When saving to session or applying settings to multiple layers at a time it's important to know what was overridden value and what not (see later).

• Dialog saves all settings to layer, later changes in global settings do not apply to customized layers. This is the current behaviour, except the two radio buttons where there is a choice to (o) Use global settings.

Another question: which settings should be saved to session for each layers?

• Overridden settings only.
• All settings.
• All settings, overriden settings marked as overridden.

To answer this question, let's think about what do we expect when we load this session later. If all preferences kept unmodified, all layers should look the same like when was saved to session. But what should happen if some settings were changed meantime, for example draw width was increased?

I think it should work similar to the way if we did not save to session and load it back. If a setting was not overridden in a layer, this should follow default setting.

Session file should store viewport and layer state as these are the main XML tags in session file. But what are these settings in detail? Viewport center and zoom only. Projection is not stored in session that can be problem with imagery layers that do not support currently selected projection.

Correct, this is a missing feature. If you think about WMS layers which require specific projection, this would be useful to store in the session file.

Layers settings that can be changed in layer dialog. There is a bug: recently introduced gamma setting is not stored.

Call it missing feature. :)

Side notes:

• JOSM calls traces as GPX lines. This is not a good practice. GPS traces can be imported not only from GPX formats (see NMEA), in the future I hope there could be even more supported formats, I plan to use GPSBabel as importer and exporter. Therefore I suggest to name them traces (as OSM calls them) or tracks (as most GPS applications call them) or something similar.

Sure.

• There are Annoying Capitalized Words on GUI, for example Draw Direction Arrows. This is not used constistently, I hope these can be lowercased to Draw direction arrows.

I guess so.

• Custom drawing settings are stored in preferences using layer name that can be changed by rename or save as a new filename. This means all problems mentioned with layer color apply to customize drawing as well.

As you have mentioned, there are two issues with layer-name based preferences:
1) When renaming a layer, the settings are lost. To fix this, the settings should simply be transferred to the new name.
2) Two layers with the same name "stick together" and share settings. This happens mainly when downloading GPX data for two regions into two layers. The fix is simple: Just add increasing number to the end of the layer name, e.g. "Downloaded GPS-data", "Downloaded GPS-data (2)", ...

This makes JOSM unavailable to transfer all session data between computers.

I don't understand.

Suggested solution:

The template method is much simpler to understand and to implement as well. I would simplify settings dialog by removing "Use global settings" exceptions. There could be a new button Load global settings at bottom of dialog that replaces all settings with global ones. In this case user can see immediately what are those global settings and can customize them for selected layers.

Great idea!

The user should be able to apply settings selectively. The question is: which settings and which layers? I suggest the following settings to preferences page, controls with default options, radio group is disabled if checkbox above is unchecked:

    [ ] Apply changes to all existing layers
        (o) Apply modified settings only
        ( ) Apply all settings

At CustomizeDrawing dialog called for one or more layers:

    [ ] Apply changes to default setting for new layers
    [ ] Apply changes to all existing layers
        (o) Apply modified settings only
        ( ) Apply all settings

I find this confusion and unnecessary.

Customize dialog should display mixed state controls for settings that are different among selected layers when multiple layers are selected.

Don't invest too much work into the dialog when multiple layers are selected. Simply filling it with the values from the first/last selected layer should be good enough.

Session file should not contain all individual settings by default. I suggest to save only values different from global settings. For example, opacity is currently saved this way. It is written only if is not equal to 100%. For convenience an option could force saving all settings into session file:

    (o) Save customized layer options only
    ( ) Save all layer options, including default values

What do you think?

Again, this option is overkill. The user should not be bothered with this choice, it should simply work as expected.

For consistency, we should use the same method for the layer-name-based preferences as for the session. In virgin state, I would expect it to follow the global settings. But once you hit the "Okay" button in the customize-dialog, I expect the configuration in that dialog to be permanent and not follow global settings any more. ("reset" button gives virginity back.)

Extending this to sessions, I see the template method more fitting as it has least surprises. (Layers that do not have their settings touched are treated special, i.e. no settings are written to the session file.) I would also split this logic between Color-setting and all other settings, simply because these are two separate menu items and one often changes the color but likes to keep the remaining settings as default.

Overall, I would say that both, the template and the override method, can be justified, the above is just what I prefer.

[kolesar]

Replying to bastiK:

Thank you for your answer.

Let's see an example. I have two GPX layers. I set width to 2 at one of the layers, 3 to the other. Later I set coloring to velocity for the two layers. All layers will have the same width, according to the first layer in list where settings are read from to the dialog. I think it's annoying.

Cannot reproduce, unless both layers have the same name.

Select both layers and right-click one to call Customize track drawing dialog. All settings will be read from first layer and all settings will be applied to all layers, including untouched settings (line with in this example).

Session file should store viewport and layer state as these are the main XML tags in session file. But what are these settings in detail? Viewport center and zoom only. Projection is not stored in session that can be problem with imagery layers that do not support currently selected projection.

Correct, this is a missing feature. If you think about WMS layers which require specific projection, this would be useful to store in the session file.

In this case session file starts to overwrite some global preferences. Where is the border of scope? Can session file override display colors, paint styles, special imagery settings?

1) When renaming a layer, the settings are lost. To fix this, the settings should simply be transferred to the new name.

I think it's not a good way. Let's have two layers with the same name with custom settings in preferences. Rename one of them. Should settings be copied or renamed in preferences? If copied, preferences file will be bloated. (This is a real problem even without renaming.) If moved, another file having the same name will lose settings. Another issue of name-based settings: let's have a layer named A and B. Rename layer A to B. Settings of layer A will be applied to layer B. Annoying.

This makes JOSM unavailable to transfer all session data between computers.

I don't understand.

Let's see an example. I would like to copy my working environment from one JOSM installation to another, for example home to office, or desktop to laptop. What should I do? If layer settings are stored in preferences file, I have to copy preferences from one computer to another that makes trouble if proxy settings or screen sizes are different. Session files currently do not transfer all settings. That's what I meant unavailable to transfer all session data.

Customize dialog should display mixed state controls for settings that are different among selected layers when multiple layers are selected.

Don't invest too much work into the dialog when multiple layers are selected. Simply filling it with the values from the first/last selected layer should be good enough.

"If the check box represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the check box in its mixed state."
​https://developer.gnome.org/hig-book/unstable/controls-check-boxes.html.en

"Mixed choice In addition to their selected and cleared states, check boxes also have a mixed state for multiple selection to indicate that the option is set for some, but not all, objects."
​https://msdn.microsoft.com/en-us/library/windows/desktop/dn742401%28v=vs.85%29.aspx

"mixed state: a condition in which an indicator must simultaneously display 2 values; common in property sheets, in property controls such as font style, when the property is shown for multiple selected objects with different property values (e.g. in a text selection, when one character is bold and another is plain)."
​http://www.usabilityfirst.com/glossary/mixed-state/

For consistency, we should use the same method for the layer-name-based preferences as for the session. In virgin state, I would expect it to follow the global settings. But once you hit the "Okay" button in the customize-dialog, I expect the configuration in that dialog to be permanent and not follow global settings any more. ("reset" button gives virginity back.)

In template model there is no virginity at all. All layer instances have their own settings. Reset button does not give virginity back, just copies current defaults to the settings dialog where you can apply them or cancel.

If there is a virgin option for layers, how does user know if a layer is in this virgin state? There is no other way than setting some global preference and check if it applies to the layer or not. It's not the right way I think.

(Layers that do not have their settings touched are treated special, i.e. no settings are written to the session file.)

In this model all layers have their settings and are written to the session file. This can also be a problem, that's why I planned option to write only non-default settings to session file.

I would also split this logic between Color-setting and all other settings, simply because these are two separate menu items and one often changes the color but likes to keep the remaining settings as default.

I would not split them, I think color settings are only separated from others because it is shared between track and marker layers. I always found annoying that I can't choose color in track drawing settings. If I choose "single color" mode, I can't choose that single color in the dialog. (Another issue: CustomizeColor action accepts only one layer.)

You prefer the method that has least surprises. What are surprises?

• When a setting in global preferences is not applied to (all/some) layers. If global settings apply only to virgin layers, it's a surprise. My plan solves this by asking if you want to apply these settings to all existing layers.

• When a setting on a layer is applied to (all/some) other layers. For example antialiasing. Or other layers having the same name. Solution: fixing the scope of settings and disabling name-based preferences.

• When modifying one option to a selection of layers and other options are overwritten. Solution: mixed state controls for multiple selection.

If you find scope options for settings dialogs complicated, they can be hidden until expert mode is selected. What do you think?

[bastiK]

Replying to kolesar:

Replying to bastiK:

Thank you for your answer.

Let's see an example. I have two GPX layers. I set width to 2 at one of the layers, 3 to the other. Later I set coloring to velocity for the two layers. All layers will have the same width, according to the first layer in list where settings are read from to the dialog. I think it's annoying.

Cannot reproduce, unless both layers have the same name.

Select both layers and right-click one to call Customize track drawing dialog. All settings will be read from first layer and all settings will be applied to all layers, including untouched settings (line with in this example).

Not perfect, but sort of what I would expect.

Session file should store viewport and layer state as these are the main XML tags in session file. But what are these settings in detail? Viewport center and zoom only. Projection is not stored in session that can be problem with imagery layers that do not support currently selected projection.

Correct, this is a missing feature. If you think about WMS layers which require specific projection, this would be useful to store in the session file.

In this case session file starts to overwrite some global preferences. Where is the border of scope? Can session file override display colors, paint styles, special imagery settings?

Interesting points. First of all, it should not change global settings permanently, i.e. after closing the last session layer or restart, the previous projection should be restored. Then, depending on the use-case, it might be a good idea to include map styles in the session. (Think of HOT distributing small work-packages to mappers.) Certainly, there is still a lot to think through.

1) When renaming a layer, the settings are lost. To fix this, the settings should simply be transferred to the new name.

I think it's not a good way. Let's have two layers with the same name with custom settings in preferences. Rename one of them. Should settings be copied or renamed in preferences? If copied, preferences file will be bloated. (This is a real problem even without renaming.)

No, this is what the preferences are designed for. If there are technical problems, we need to solve them on a technical level.

If moved, another file having the same name will lose settings. Another issue of name-based settings: let's have a layer named A and B. Rename layer A to B. Settings of layer A will be applied to layer B. Annoying.

I don't think these issues are that big of a deal, but overall, I would agree that saving the settings based on the layer name is not the proper way to do it but a pragmatic hack that has several advantages and disadvantages in practice.

This makes JOSM unavailable to transfer all session data between computers.

I don't understand.

Let's see an example. I would like to copy my working environment from one JOSM installation to another, for example home to office, or desktop to laptop. What should I do? If layer settings are stored in preferences file, I have to copy preferences from one computer to another that makes trouble if proxy settings or screen sizes are different. Session files currently do not transfer all settings. That's what I meant unavailable to transfer all session data.

Okay.

Customize dialog should display mixed state controls for settings that are different among selected layers when multiple layers are selected.

Don't invest too much work into the dialog when multiple layers are selected. Simply filling it with the values from the first/last selected layer should be good enough.

"If the check box represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the check box in its mixed state."
​https://developer.gnome.org/hig-book/unstable/controls-check-boxes.html.en

"Mixed choice In addition to their selected and cleared states, check boxes also have a mixed state for multiple selection to indicate that the option is set for some, but not all, objects."
​https://msdn.microsoft.com/en-us/library/windows/desktop/dn742401%28v=vs.85%29.aspx

"mixed state: a condition in which an indicator must simultaneously display 2 values; common in property sheets, in property controls such as font style, when the property is shown for multiple selected objects with different property values (e.g. in a text selection, when one character is bold and another is plain)."
​http://www.usabilityfirst.com/glossary/mixed-state/

Not saying it is wrong, but I would guess only a handful of people know the multiselect-customize feature exists and of those, only a fraction is actually using it. So why spend more development time on it, than all users combined will ever save? :)

For consistency, we should use the same method for the layer-name-based preferences as for the session. In virgin state, I would expect it to follow the global settings. But once you hit the "Okay" button in the customize-dialog, I expect the configuration in that dialog to be permanent and not follow global settings any more. ("reset" button gives virginity back.)

In template model there is no virginity at all. All layer instances have their own settings. Reset button does not give virginity back, just copies current defaults to the settings dialog where you can apply them or cancel.

If there is a virgin option for layers, how does user know if a layer is in this virgin state? There is no other way than setting some global preference and check if it applies to the layer or not. It's not the right way I think.

You have a point. Then I think the current system isn't too bad, but needs a little cleanup / redesign:

• When not in expert mode, the top part is crippled.
• First option "Create markers when reading GPX" makes no sense for layer-specific settings.
• Next it should not say "Local files", but "Yes" / "No".
• The disabling labels in the first section is inconsistent, e.g. "Draw direction arrows" gets gray, but "Maximum length" doesn't.
• "Drawing width of GPX lines" belongs in the previous section.
• "use global" should be possible for every option, it should be designed more consistently with indentation and possibly boxes around grouped options. E.g. in last section, it would be better to have a separate checkbox "global settings", because then you could see what the current global setting actually is in the disabled radio button list below.
• Add a Scrollbox for smaller screens.

(Layers that do not have their settings touched are treated special, i.e. no settings are written to the session file.)

In this model all layers have their settings and are written to the session file. This can also be a problem, that's why I planned option to write only non-default settings to session file.

I would also split this logic between Color-setting and all other settings, simply because these are two separate menu items and one often changes the color but likes to keep the remaining settings as default.

I would not split them, I think color settings are only separated from others because it is shared between track and marker layers. I always found annoying that I can't choose color in track drawing settings. If I choose "single color" mode, I can't choose that single color in the dialog. (Another issue: CustomizeColor action accepts only one layer.)

Please keep in mind that color is by far the most useful thing to customize for different layers and understandable by user with average technical grasp while the other dialog is overwhelmingly loaded with complicated options.

If you want to merge it, maybe consider multiple tabs.

You prefer the method that has least surprises. What are surprises?

• When a setting in global preferences is not applied to (all/some) layers. If global settings apply only to virgin layers, it's a surprise. My plan solves this by asking if you want to apply these settings to all existing layers.

I think it is a sign of bad UI design if you have to ask such a question. Could be the least bad option, but still not good. ;)

• When a setting on a layer is applied to (all/some) other layers. For example antialiasing. Or other layers having the same name. Solution: fixing the scope of settings and disabling name-based preferences.

I would change name-based preference to file-name based preference (disabling it for layers not saved to file).

• When modifying one option to a selection of layers and other options are overwritten. Solution: mixed state controls for multiple selection.

As you like, but I'd rather remove the multiple selection feature than have it complicate/worsen the design of the single-layer dialog.

If you find scope options for settings dialogs complicated, they can be hidden until expert mode is selected. What do you think?

Not sure it is very helpful in that case to make it expert-dependent.

[kolesar]

Replying to bastiK:

First of all, it should not change global settings permanently, i.e. after closing the last session layer or restart, the previous projection should be restored.

Reverting projection later would be a real surprise for the user. Last session layer is not clear because layers can be merged with other (non-session) layers. Even multiple sessions can be loaded at a time. I suggest to save projection to session file and a dialog can ask user if current projection is different from saved session.

Let me introduce a new name for your concept: project. Just like in Eclipse or similar software. A project can have its own preferences. When it is opened, global preferences are overridden. When it is closed, global preferences apply again. I'm not sure if this feature is needed into JOSM but keep it in our mind.

Important difference: projects are mutually exclusive, session files are not. You can have different groups of layers ins session files and load them together.

Not saying it is wrong, but I would guess only a handful of people know the multiselect-customize feature exists and of those, only a fraction is actually using it. So why spend more development time on it, than all users combined will ever save?

20,000+ contributors used JOSM in last year. If only 1% of them needs to customize multiple GPX layers at a time, that is 200. That is still a large number.

First option "Create markers when reading GPX" makes no sense for layer-specific settings.

I think this feature was the first bad surprise (= WTF experience) for me. Loaded 3 GPX files and got 6 layers. Why are markers separated from tracks? If markers are separated, then why are routes mixed with tracks? I understand markers should be switched on/off separately, but this solution is not the best one. Combining them would be much better, there could be an additional column in layers list to show/hide markers on GPX layers.

I would make a three-way option for this with backwards compatibility:

    ( ) Create a separate layer for markers
    (o) Handle markers together with tracks and routes
    ( ) Do not load markers at all

"Local files"

It is another big pain of OSM. Not JOSM, but tracks API. It's a shame that API can't handle track segments. I think word "local files" is misleading. When you download traces from OSM API and save to GPX file it becomes a local file. I know a flag is placed called "from-server" that tells JOSM to handle this file as OSM API trace when loaded again. Most users don't know this. Dialiog should help them to understand what is happening.

I would suggest the following settings to GUI:

    Maximum length between points where a line will be drawn
    [   ] meters for traces downloaded from OSM server (that are not split to segments)
    [   ] meters for other traces (usually segmented where GPS signal lost)

"use global" should be possible for every option

Have you changed your mind or do I misunderstand your words? In your previous comment you have written: I think a "use global" option for each individual setting is impractical and awkward.

If you want to merge it, maybe consider multiple tabs.

I have planned to keep spearate menu item for color settings. I suggested to include a button on track draw settings to set color directly from there.

    Track and point coloring
    (o) Single color: [     ] (color chooser)
    ( ) Velocity
    [...]

I would change name-based preference to file-name based preference (disabling it for layers not saved to file).

Filename-based preference is not better that name-based. If only basename is saved (without full path), it is ambiguous. If full path is saved, portability will be lost. Layer settings should be saved to files and session files.

When modifying one option to a selection of layers and other options are overwritten. Solution: mixed state controls for multiple selection.

As you like, but I'd rather remove the multiple selection feature than have it complicate/worsen the design of the single-layer dialog.

Then I would add a notice to dialog if selected layers had mixed settins: Multiple layers were selected and some of the settings were different. You can see the settings of topmost layer. Modified settings will be applied to the selected layers, other settings will not be touched.

Mixed state controls not needed. Howewer, there are several problems with this.

• Not visible which settings are different in selection.
• Not clear what does modified settings mean.
  • If touched settings are applied (even when reverted to their initial state), there is no visual feedback what were touched.
  • If modified settings are applied (settings different from their initial state), you can't apply a setting to all layers that equals original state of topmost layer. Workaround: set it to different value, OK, set it to back, OK.

Current implementation overwrites every setting on the dialog. It's the most simple implementation but user is unable to change a subset of settings on more than layer at a time.

Suggested solution shows mixed state controls only if selection was multiple and only for settings that have different values. I would simplify tristate checkboxes to mixed initial state checkboxes that can set only to on/off states once modified. All other controls beave the same way, only initial state is mixed. Can you accept this?

[bastiK]

Replying to kolesar:

Replying to bastiK:

First of all, it should not change global settings permanently, i.e. after closing the last session layer or restart, the previous projection should be restored.

Reverting projection later would be a real surprise for the user. Last session layer is not clear because layers can be merged with other (non-session) layers. Even multiple sessions can be loaded at a time. I suggest to save projection to session file and a dialog can ask user if current projection is different from saved session.

Let me introduce a new name for your concept: project. Just like in Eclipse or similar software. A project can have its own preferences. When it is opened, global preferences are overridden. When it is closed, global preferences apply again. I'm not sure if this feature is needed into JOSM but keep it in our mind.

Important difference: projects are mutually exclusive, session files are not. You can have different groups of layers ins session files and load them together.

Sessions are useful, but they still feel like a gentle extension and not a fully integrated concept. (For example, it would make sense to auto-save the current session on crash and not just the data-layers. Another idea would be to have an option to automatically save and restore the session when JOSM is closed and started again.)

What you call project is generally the better and clearer concept, but it is not easy to apply it to JOSM in a consistent manner.

First option "Create markers when reading GPX" makes no sense for layer-specific settings.

I think this feature was the first bad surprise (= WTF experience) for me. Loaded 3 GPX files and got 6 layers. Why are markers separated from tracks? If markers are separated, then why are routes mixed with tracks? I understand markers should be switched on/off separately, but this solution is not the best one. Combining them would be much better, there could be an additional column in layers list to show/hide markers on GPX layers.

+1, but if you want to take on this project, please open another ticket and describe you plans in detail to give people a chance to comment. This is very old code, keep the audio-stuff in mind.

I would make a three-way option for this with backwards compatibility:

    ( ) Create a separate layer for markers
    (o) Handle markers together with tracks and routes
    ( ) Do not load markers at all

Having two systems side-by-side is a burden for developers, so we'd aim to remove the old one after some time. This works better if the setting is hidden (Einstein). If your change is an improvement, you should have the confidence to say that users should stop complaining and get used to it. ;)

"Local files"

It is another big pain of OSM. Not JOSM, but tracks API. It's a shame that API can't handle track segments. I think word "local files" is misleading. When you download traces from OSM API and save to GPX file it becomes a local file. I know a flag is placed called "from-server" that tells JOSM to handle this file as OSM API trace when loaded again. Most users don't know this. Dialiog should help them to understand what is happening.

I would suggest the following settings to GUI:

    Maximum length between points where a line will be drawn
    [   ] meters for traces downloaded from OSM server (that are not split to segments)
    [   ] meters for other traces (usually segmented where GPS signal lost)

I don't think there is generally a need to set this option. These are technicalities the user should not need to be confronted with.

The options "None", "Local files", "All" can be simplified to "Yes" and "No", the differentiation between local and server files is very selective, inconsistent and (IMO) not needed.

"use global" should be possible for every option

Have you changed your mind or do I misunderstand your words? In your previous comment you have written: I think a "use global" option for each individual setting is impractical and awkward.

I still think it is would be awkward to have this option separately for each individual setting. But you convinced me, that we must have an explicit indication if global settings are used for a layer or not. Given that, there are still multiple possibilities:

(a) a single checkbox on top of the dialog, which enables/disables the entire rest of the dialog
(b) groups of options that can be set to global, then will enable/disable a certain section of the dialog
(c) one checkbox for each option

(b) is closest to what we have now and seems best to me.

If you want to merge it, maybe consider multiple tabs.

I have planned to keep spearate menu item for color settings. I suggested to include a button on track draw settings to set color directly from there.

    Track and point coloring
    (o) Single color: [     ] (color chooser)
    ( ) Velocity
    [...]

Sounds good!

I would change name-based preference to file-name based preference (disabling it for layers not saved to file).

Filename-based preference is not better that name-based. If only basename is saved (without full path), it is ambiguous. If full path is saved, portability will be lost. Layer settings should be saved to files and session files.

Please keep in mind the use-case I described in the first comment! It means the colors I have carefully selected for my gpx-files will no longer "stick", but be forgotten when JOSM is closed. This is an unnecessary removal of a useful feature.

Also I don't really see the necessity to write the settings to the gpx-files as well. Think of html and css. One file has the data and the other the styling information.

When modifying one option to a selection of layers and other options are overwritten. Solution: mixed state controls for multiple selection.

As you like, but I'd rather remove the multiple selection feature than have it complicate/worsen the design of the single-layer dialog.

Then I would add a notice to dialog if selected layers had mixed settins: Multiple layers were selected and some of the settings were different. You can see the settings of topmost layer. Modified settings will be applied to the selected layers, other settings will not be touched.

Mixed state controls not needed. Howewer, there are several problems with this.

• Not visible which settings are different in selection.
• Not clear what does modified settings mean.
  • If touched settings are applied (even when reverted to their initial state), there is no visual feedback what were touched.
  • If modified settings are applied (settings different from their initial state), you can't apply a setting to all layers that equals original state of topmost layer. Workaround: set it to different value, OK, set it to back, OK.

Current implementation overwrites every setting on the dialog. It's the most simple implementation but user is unable to change a subset of settings on more than layer at a time.

Suggested solution shows mixed state controls only if selection was multiple and only for settings that have different values. I would simplify tristate checkboxes to mixed initial state checkboxes that can set only to on/off states once modified. All other controls beave the same way, only initial state is mixed. Can you accept this?

Yes, I don't really care for multi-select settings - just that it shouldn't compromise the design of the single layer settings dialog.

[kolesar]

Replying to bastiK:

Sessions are useful, but they still feel like a gentle extension and not a fully integrated concept. (For example, it would make sense to auto-save the current session on crash and not just the data-layers. Another idea would be to have an option to automatically save and restore the session when JOSM is closed and started again.)

Both ideas are great. I'm going to implement them.

I don't think there is generally a need to set this option. These are technicalities the user should not need to be confronted with.

These are the 3rd and 4th options on the first page and first tab of preferences. Fortunately only in expert mode. In simple mode dialog is crapped as you have mentioned. :-(

Please keep in mind the use-case I described in the first comment! It means the colors I have carefully selected for my gpx-files will no longer "stick", but be forgotten when JOSM is closed. This is an unnecessary removal of a useful feature.

In that comment you have mentioned saving settings to session file. Then I redesigned plan to save settings to session. If you customize layer settings but don't save the gpx file nor the session file, it's quite acceptable from a new session to load your gpx file with default settings.

If you really need current name-based feature, you can still have an option: For backwards compatibility saving color to preferences should be an option but not default. Name-based coloring causes the most suprises as I have started this ticket with this title. That's why I suggest to replace this.

(b) groups of options that can be set to global, then will enable/disable a certain section of the dialog

Please keep in mind the use-case I have described before: I have lots of track layers, some of them have custom settings and then I want to change one particular setting for all (or just a selection of layers). If I can set global/local values only for a group of settings, then all members of that group will be set, not only the one setting I need to change.

Let's see a simple example. There are only three settings of layer drawing: width, direction arrows and color. There are global settings in preferences and local settings for each layers. Global settings are 1-false-gray, respectively.

User story:

1. Set width to 3 for the first track layer.
2. Set direction arrows for all track layers.

How are these steps performed?

template model: All new layers become 1-false-gray. All these settins are stored in layer instance. Global values are only used as a template to create new instances, hence the model name.

1. Select layer, right-click and and set width to 3. Layer will have 3-false-gray.

2. Select all track layers, right-click. Dialog shows mixed-false-gray, set direction arrows to true. First track layer will have 3-true-gray, other track layers will have 1-true-gray because untouched mixed control will not affect layers.

    [####] width
    [ ]    direction arrows
    [gray] color

If user would sets direction arrows at preferences, it would not affect existing layers. That's where suggested options help:

    [ ] Apply changes to all existing layers
    (o) Apply modified settings only
    ( ) Apply all settings

Only direction arrow setting will be applied to existing layers. It is simple and straightforward.

override model: new layers become null-null-null. No settings are overridden yet. Global values apply.

1. a single checkbox on top of the dialog, which enables/disables the entire rest of the dialog

1. Select first layer. Checkbox shows [x] use global settings; user clicks this checkbox, enables individual settings. 1-false-gray is shown from global options. Set width to 3. Layer will store all settings (3-false-gray) for override.

2. Select all layers. Checkbox for using global settings should display mixed state because global settings are overridden for first layer but not for other layers. If use global settings are unchecked, width should display mixed control because overridden value is different among layers. (In this example only one layer has an override value but there can be a layer with different width, too.) If we don't use mixed state controls and this dialog shows settings from layer one, will show unchecked and values 3-false-gray. Disabling "use global" sets override for all layers, width will be set to 3 for all layers. That is a surprise for the user.

If user sets direction arrows at global preferences, first layer will not be affected because it overrides global settings. This is also a suprise.

2. groups of options that can be set to global, then will enable/disable a certain section of the dialog

1. Suppose width and direction arrows are in group A, color is in group B. User customizes group A, sets width to 3. Layer will store 3-false-null. Direction arrows will also have overridden settings.

2. Same happens as in a/2 because width and direction arrows are in the same group.

3. one checkbox for each option

1. Three checkboxes will appear, initially all checked: [x] use global setting; uncheck for width and set to 3. Layer will have 3-null-null.

2. dialog will look like this ([#] means mixed state control)

       [#] use global setting | [####] width
       [x] use global setting | [ ]    direction arrows
       [x] use global setting | [gray] color
   

If user sets direction arrows at global preferences, all layers will follow new setting as no layers have overridden setting for direction arrows. Width keeps untouched.

You can see there are more controls, more clicks and more suprises when using override model, except version (c) with less surprises but most use global checkboxes.

Therefore I suggest to use template model with mixed state controls and options to copy modified/all settings to other layers and/or to defaults.

• mixed state controls appear
  • only if selection is multiple
  • only if the setting is different
  • only at initial state, then behave normally

• options to copy settings to existing layers appear
  • only when there are track layers and settings are set in preferences page
  • only when there are track layers not counting the one being modified

I think template model with copy options is easier to understand and follow what happens. Important arguments:

override model:

• Settings page is different at global preferences and layer. At least the only use global checkbox but version (b) and (c) have more use global checkboxes.

• You are unable to unify layers in one step. Instead, you should set options globally, then select all layers and set them to use global options. It counts three steps.

• Unless you select all track layers you can't be sure which layers will be affected by changing global options. Selecting all layers can be a pain if there are many of them, interleaved by other types of layers that prevent you from select with Shift+click.

template model:

• Settings dialog looks and acts exactly the same way at global preferences and layer. You can set something in preferences and apply to all layers without selecting all layers and set options in right-click menu.

• You can unify layers in one step. Either using preferences page or customize dialog of one of the layers by selecting option Apply changes to all existing layers.

• You can be sure all track layers will be affected with the change if you apply changes to all layers.

Are you convinced enough?

[bastiK]

Replying to kolesar:

Replying to bastiK:

Please keep in mind the use-case I described in the first comment! It means the colors I have carefully selected for my gpx-files will no longer "stick", but be forgotten when JOSM is closed. This is an unnecessary removal of a useful feature.

In that comment you have mentioned saving settings to session file. Then I redesigned plan to save settings to session. If you customize layer settings but don't save the gpx file nor the session file, it's quite acceptable from a new session to load your gpx file with default settings.

If you really need current name-based feature, you can still have an option: For backwards compatibility saving color to preferences should be an option but not default. Name-based coloring causes the most suprises as I have started this ticket with this title. That's why I suggest to replace this.

I may be biased as I personally use and enjoy the feature. Yes, the name-based settings are a hack, but file-name-based settings would be perfectly fine and have none of the surprises or disadvantages you mentioned. Why do you want to get rid of the (improved) feature?

Btw. "sticky" settings for files that only get opened are not unheard-of. My video-player saves the last play-back position for every file I have opened and my image viewer remembers the rotation angle - without modifying the file. Obviously this isn't portable, but who cares?

(b) groups of options that can be set to global, then will enable/disable a certain section of the dialog

Please keep in mind the use-case I have described before: I have lots of track layers, some of them have custom settings and then I want to change one particular setting for all (or just a selection of layers). If I can set global/local values only for a group of settings, then all members of that group will be set, not only the one setting I need to change.

Let's see a simple example. There are only three settings of layer drawing: width, direction arrows and color. There are global settings in preferences and local settings for each layers. Global settings are 1-false-gray, respectively.

User story:

1. Set width to 3 for the first track layer.
2. Set direction arrows for all track layers.

How are these steps performed?

template model: All new layers become 1-false-gray. All these settins are stored in layer instance. Global values are only used as a template to create new instances, hence the model name.

1. Select layer, right-click and and set width to 3. Layer will have 3-false-gray.

2. Select all track layers, right-click. Dialog shows mixed-false-gray, set direction arrows to true. First track layer will have 3-true-gray, other track layers will have 1-true-gray because untouched mixed control will not affect layers.

    [####] width
    [ ]    direction arrows
    [gray] color

If user would sets direction arrows at preferences, it would not affect existing layers. That's where suggested options help:

    [ ] Apply changes to all existing layers
    (o) Apply modified settings only
    ( ) Apply all settings

Only direction arrow setting will be applied to existing layers. It is simple and straightforward.

Are you convinced enough?

We clearly put importance on different aspects. I believe you changes will be an overall improvement, so please go ahead!

[kolesar]

Replying to bastiK:

I may be biased as I personally use and enjoy the feature. Yes, the name-based settings are a hack, but file-name-based settings would be perfectly fine and have none of the surprises or disadvantages you mentioned. Why do you want to get rid of the (improved) feature?

I do not want to get rid of, just to have an option to disable it.

Btw. "sticky" settings for files that only get opened are not unheard-of. My video-player saves the last play-back position for every file I have opened and my image viewer remembers the rotation angle - without modifying the file. Obviously this isn't portable, but who cares?

Do you mean filename-based preferences as basename or full path? Current implementation uses only basename (or custom layer name) that causes surprises.

[bastiK]

Replying to kolesar:

Replying to bastiK:

I may be biased as I personally use and enjoy the feature. Yes, the name-based settings are a hack, but file-name-based settings would be perfectly fine and have none of the surprises or disadvantages you mentioned. Why do you want to get rid of the (improved) feature?

I do not want to get rid of, just to have an option to disable it.

As long as it is a hidden option and enabled by default, there is no harm in that.

Btw. "sticky" settings for files that only get opened are not unheard-of. My video-player saves the last play-back position for every file I have opened and my image viewer remembers the rotation angle - without modifying the file. Obviously this isn't portable, but who cares?

Do you mean filename-based preferences as basename or full path? Current implementation uses only basename (or custom layer name) that causes surprises.

Full path (or hash of full path if the length is an issue).

[kolesar]

Let me summarize discussion.

• Name-based saving to preferences will be converted to filename-based, using full path, for only saved/loaded files. That keeps functionality to remember settings of GPX files without saving themselves or saving a session file.

• A new hidden enable/disable switch will be for saving layer settings to preferences, default is enable.

• GPS points preferences page and related dialog Customize track drawing will be refactored with mixed state controls for multiple selection and options for applying changes to all layers / default settings.

• Color chooser will be available from this dialog directly. Separate popup menu will be still available in layer dialog.

• Customized layer options will be saved to session file and applied on load.

• Saving layer options to GPX file will be an option at GPX export options dialog similar to [x] Add author information.

• Saving email address to GPX files will be fixed.

Do you agree?

[bastiK]

Replying to kolesar:

Let me summarize discussion.

• Name-based saving to preferences will be converted to filename-based, using full path, for only saved/loaded files. That keeps functionality to remember settings of GPX files without saving themselves or saving a session file.

• A new hidden enable/disable switch will be for saving layer settings to preferences, default is enable.

• GPS points preferences page and related dialog Customize track drawing will be refactored with mixed state controls for multiple selection and options for applying changes to all layers / default settings.

• Color chooser will be available from this dialog directly. Separate popup menu will be still available in layer dialog.

• Customized layer options will be saved to session file and applied on load.

• Saving layer options to GPX file will be an option at GPX export options dialog similar to [x] Add author information.

Having 3 different systems to to save the layer options is a bit ridiculous. The maintenance effort is quite high. In addition, I don't really see why it is needed: If you only care to keep the settings locally, in near future, then the automatic file-name based settings will do. I guess this is by far the most common situation. If you are keen to keep the settings forever or transfer it to a different computer, it can be saved in a session file. Admittedly, this may not be obvious to everyone.

Finally this high level of redundancy leads to conflicts when multiple settings are present: What will have the highest priority? Will the user also expect this precedence?

If you still think it is absolutely needed, could you please write a separate patch for this feature? I don't promise to apply it, but someone else might. ;)

• Saving email address to GPX files will be fixed.

Do you agree?

+1 for the rest.

[kolesar]

Replying to bastiK:

Finally this high level of redundancy leads to conflicts when multiple settings are present: What will have the highest priority? Will the user also expect this precedence?

Main goal of saving display properties to files is to increase portability. This feature will be disabled by default. If user enables checkbox it remembers state as add author information does.

Priority of settings: session, filename-based preferences, file. Therefore if you load a session, that overrides other settings. If you open a track file and you have stored settings in preferences for that filename, it will be used even if file has embedded settings. If your preferences file does not have settings for that file or you have disabled using filename-based preferences then embedded settings from file will apply.

[bastiK]

Replying to kolesar:

Replying to bastiK:

Finally this high level of redundancy leads to conflicts when multiple settings are present: What will have the highest priority? Will the user also expect this precedence?

Main goal of saving display properties to files is to increase portability. This feature will be disabled by default. If user enables checkbox it remembers state as add author information does.

Another analogy is the .epub format for e-books: You would of course store author and title information in the file, but not font and font-size, as it depends on the device, the user's preference and eye-sight.

Priority of settings: session, filename-based preferences, file. Therefore if you load a session, that overrides other settings. If you open a track file and you have stored settings in preferences for that filename, it will be used even if file has embedded settings. If your preferences file does not have settings for that file or you have disabled using filename-based preferences then embedded settings from file will apply.

Then this will only be used in very rare circumstances, not adding any real new functionality. I don't think it justifies the additional maintenance required with 3-fold redundant settings storage code.

It was a good idea under the premise, that name-based "sticky" settings get dropped and not considering sessions. But we should keep sticky settings and adding this information to the session file is a no-brainer and should have been done in the first place.

I'm not convinced, please convince other team members if you must! :)

[kolesar]

Replying to bastiK:

Then this will only be used in very rare circumstances, not adding any real new functionality. I don't think it justifies the additional maintenance required with 3-fold redundant settings storage code.

There should not be redundant code if settings would be written to and read from .jos and .gpx with the same XML library. The problem is they use absolutely diferent ways to write/read XML:

• SessionWriter org.w3c.dom.Document
• SessionReader org.w3c.dom.Document
• GpxWriter java.io.PrintWriter
• GpxReader javax.xml.parsers.SAXParser

I understand that GPX files can be very large and probably this is the fastest way to do it.

To avoid redundancy in code, I stop thinking about adding display settings to GPX files. We agreed in all other topics, right?

[bastiK]

Replying to kolesar:

Replying to bastiK:

Then this will only be used in very rare circumstances, not adding any real new functionality. I don't think it justifies the additional maintenance required with 3-fold redundant settings storage code.

There should not be redundant code if settings would be written to and read from .jos and .gpx with the same XML library. The problem is they use absolutely diferent ways to write/read XML:

• SessionWriter org.w3c.dom.Document
• SessionReader org.w3c.dom.Document
• GpxWriter java.io.PrintWriter
• GpxReader javax.xml.parsers.SAXParser

I understand that GPX files can be very large and probably this is the fastest way to do it.

Right, DOM does not work for GPX speed- and memory-wise. On the other hand SAX/StAX is not a good idea for sessions when plugins can add their custom session readers and writers: It would be much too easy to break the XML structure in one way or another and there is not much we could do about it.

To avoid redundancy in code, I stop thinking about adding display settings to GPX files. We agreed in all other topics, right?

Yes.