Creating and using presets
Creating and using presets
The creation of presets was discussed in the forum.
Opinions on this are not unanimous at the moment. For example, I believe that when creating a preset B, it is important to pay attention to the changes made by a previously recalled preset A. For example, if A has hidden the toolbars, but they should be shown in B, then they must be explicitly shown in B, even if the toolbars are shown by default.
I have an idea how to work around this and all other problems with the presets.
Each time you exit LM, a record is created containing the current setting. This record in a configuration file is evaluated the next time LM is started and enables LM to show itself to the user in exactly the same constellation in which the program was terminated.
This circumstance could be used for the creation of presets.
You set LM the way you want it for a particular situation, such as navigating a bike.
Now you create a preset for navigating with the bike and only need to specify the name of this preset. Everything else is done automatically. The app creates and saves a record like it does when you exit the application.
If the preset is then called up once, the app can use the saved data set to create exactly the constellation that the user specified when creating the preset.
Once again as a summary:
- To create a preset, the user makes the desired setting and thus creates the preset.
- The program creates a data set with the current settings for a preset and saves this in a list of presets.
- If a preset is called up, the program opens the corresponding data record from the list and creates the saved constellation.
I like this idea 
No, I don't agree (and not because your spamming of other threads with a reference (not even a link) to this is a bit annoying).
The problem is that the system you propose is less versatile than the existing one - much so. It always recreates every setting, while the current system allows to do "incremental" change sets: I can have a biking preset that doesn't handle maps at all, and other presets to activate maps with certain themes. And where to stop, what settings to store? Some things might be coincidental in one situation. Perhaps there's a new Locus setting you like, but then your preset from last version resets this to default?
The current system is more for experts, sure, but it gives you fine control overc the behaviour - you know what you get.
No, I don't agree (and not because your spamming of other threads with a reference (not even a link) to this is a bit annoying).
The problem is that the system you propose is less versatile than the existing one - much so. It always recreates every setting, while the current system allows to do "incremental" change sets: I can have a biking preset that doesn't handle maps at all, and other presets to activate maps with certain themes. And where to stop, what settings to store? Some things might be coincidental in one situation. Perhaps there's a new Locus setting you like, but then your preset from last version resets this to default?
The current system is more for experts, sure, but it gives you fine control overc the behaviour - you know what you get.
They say the system I'm proposing is less versatile than the existing one. They believe this is because each setting is always created from scratch, while the current system allows for "incremental" sets of changes. I cannot agree with this argument.
For the user, a preset is a preset. How a preset is handled internally is of no importance to the user. It is important for the user that he gets the constellation he wants with a preset and nothing else.
The existing system does not always live up to this idea. An example:
A user creates a preset for hiking. Various functionalities are included in this preset. The user then creates a preset for "Auto". Similar functionalities are included in this preset as for "Wander", but with different parameters, for example for the autozoom. However, functionalities are also integrated that are not desired for hiking, for example hiding the control bars or the omission of the shading.
Now this user drives (with the activated auto-preset) to a hiker's parking lot. Here he switches from the auto preset to the hiking preset. The user finds that the control bars are not displayed and he also misses the shading.
What happened? The user didn't know that he would have had to specify in the hiking preset that the control bars should be displayed and that the maps should also be shaded.
This would not happen, for example, if a user makes a specific setting that he would like to have when hiking, for example, and then saves this setting as a preset.
The procedure I have described for creating presets also simplifies things for the programmer, he does not need to create and manage two settings dialogs, one for the functionalities that are to be taken into account by a preset and then a second one for the user then needs to specify the settings.
Creating a preset where a data set is created and saved from the existing settings brings benefits for both sides, the user really gets what he wants and the programmer can use it to create the data set and produce a specific constellation from a Such a data set can use the same code that he wrote for saving the settings when closing the app and the same applies to the activation of a preset, i.e. the creation of a constellation as it is saved in the preset. The same code is used here as when opening the app.
Regarding your statement that the current system is certainly more for experts, but it gives you a fine control over the behavior - you know what you get, I can only ask the one question: "Was Locus Mapp for a large majority or only programmed for some experts?"
They say the system I'm proposing is less versatile than the existing one. They believe this is because each setting is always created from scratch, while the current system allows for "incremental" sets of changes. I cannot agree with this argument.
For the user, a preset is a preset. How a preset is handled internally is of no importance to the user. It is important for the user that he gets the constellation he wants with a preset and nothing else.
The existing system does not always live up to this idea. An example:
A user creates a preset for hiking. Various functionalities are included in this preset. The user then creates a preset for "Auto". Similar functionalities are included in this preset as for "Wander", but with different parameters, for example for the autozoom. However, functionalities are also integrated that are not desired for hiking, for example hiding the control bars or the omission of the shading.
Now this user drives (with the activated auto-preset) to a hiker's parking lot. Here he switches from the auto preset to the hiking preset. The user finds that the control bars are not displayed and he also misses the shading.
What happened? The user didn't know that he would have had to specify in the hiking preset that the control bars should be displayed and that the maps should also be shaded.
This would not happen, for example, if a user makes a specific setting that he would like to have when hiking, for example, and then saves this setting as a preset.
The procedure I have described for creating presets also simplifies things for the programmer, he does not need to create and manage two settings dialogs, one for the functionalities that are to be taken into account by a preset and then a second one for the user then needs to specify the settings.
Creating a preset where a data set is created and saved from the existing settings brings benefits for both sides, the user really gets what he wants and the programmer can use it to create the data set and produce a specific constellation from a Such a data set can use the same code that he wrote for saving the settings when closing the app and the same applies to the activation of a preset, i.e. the creation of a constellation as it is saved in the preset. The same code is used here as when opening the app.
Regarding your statement that the current system is certainly more for experts, but it gives you a fine control over the behavior - you know what you get, I can only ask the one question: "Was Locus Mapp for a large majority or only programmed for some experts?"
Are you basically saying you want a "save current settings as a preset" option as that currently is how it works, when you make a new preset it copeis current settings, then you can just edit it to remove the bits that you want unchanegd when the preset is selected
so i have a radar preset where all it does is change the map, and i have otehr presets that change everything
i can just one one preset after the other..
I cant see what your suggesting has any advantage,,,
Are you basically saying you want a "save current settings as a preset" option as that currently is how it works, when you make a new preset it copeis current settings, then you can just edit it to remove the bits that you want unchanegd when the preset is selected
so i have a radar preset where all it does is change the map, and i have otehr presets that change everything
i can just one one preset after the other..
I cant see what your suggesting has any advantage,,,
You mean that currently the current settings are applied to a preset. This is only partially correct, current settings are adopted, but not all current settings are adopted.
However, all settings are applied to the configuration file when the app is closed. After a reboot, LM will show up exactly as you exited the application. This starts with the map and ends with the control bars. Such a setting could also be used as a preset. So the settings for a preset are not defined in a list, but created in active mode and then saved as a preset. When the preset is recalled later, everything will be restored as it was when it was recorded.
And there is another advantage with my suggestion: Not all presets are currently honored with the same settings. An example:
A user has specified in the basic setting that shading should be used for the display of the maps.
Now this user creates a preset for navigation with a car. Since he knows from experience that, especially in a landscape with mountains, the clarity suffers when moving quickly due to the shading, the user deactivates the shading in the preset.
This user creates another preset for hiking. Since the shading of the map does not interfere with hiking, he does not take the shading into account in the preset.
Now when that user uses the preset for the car, the map is shown without shading. If he then activates the preset for hiking, he will be amazed to see that the maps are shown without shading.
For the creation of each preset, the user should have set the environment as he wishes for the preset to be created, i.e. in one case without shading, in the other case with. Now, to create a preset, the user only needs to assign a name because LM knows that a record must be created and saved for the preset, just like closing the application for the config file.
Just as after each start the environment of LM is restored via the config file exactly as it was before it was closed, so (according to my suggestion) the environment of LM for each preset is restored exactly as it was when it was created of the preset was.
You mean that currently the current settings are applied to a preset. This is only partially correct, current settings are adopted, but not all current settings are adopted.
However, all settings are applied to the configuration file when the app is closed. After a reboot, LM will show up exactly as you exited the application. This starts with the map and ends with the control bars. Such a setting could also be used as a preset. So the settings for a preset are not defined in a list, but created in active mode and then saved as a preset. When the preset is recalled later, everything will be restored as it was when it was recorded.
And there is another advantage with my suggestion: Not all presets are currently honored with the same settings. An example:
A user has specified in the basic setting that shading should be used for the display of the maps.
Now this user creates a preset for navigation with a car. Since he knows from experience that, especially in a landscape with mountains, the clarity suffers when moving quickly due to the shading, the user deactivates the shading in the preset.
This user creates another preset for hiking. Since the shading of the map does not interfere with hiking, he does not take the shading into account in the preset.
Now when that user uses the preset for the car, the map is shown without shading. If he then activates the preset for hiking, he will be amazed to see that the maps are shown without shading.
For the creation of each preset, the user should have set the environment as he wishes for the preset to be created, i.e. in one case without shading, in the other case with. Now, to create a preset, the user only needs to assign a name because LM knows that a record must be created and saved for the preset, just like closing the application for the config file.
Just as after each start the environment of LM is restored via the config file exactly as it was before it was closed, so (according to my suggestion) the environment of LM for each preset is restored exactly as it was when it was created of the preset was.
Hello Konrad, guys,
thanks for the idea. When I was thinking about creating "Presets", there were generally two options:
1. current system > Every preset is defined by the bunch of settings that are modified upon activation and once activated, it "only" overwrites current active settings and has no on/off state
2. full config option > All main app settings can be saved and later restored. The app always works in any "Preset". Simply: you activate a "Preset" and live inside. All changes are automatically saved in this preset. This system is used by for example OSMAnd if I remember correctly. And this is very close to what you describe.
Both options have their advantages and disadvantages. The second option is easier to understand and offers to control all options. The first current system is limited in the number of options but offers a lot higher flexibility.
---
Rework of current system 2. to new system 1. ... uff, a major task :).
In case, most of the users will vote for the second option, I'm willing to think more about it ... 🫥
Hello Konrad, guys,
thanks for the idea. When I was thinking about creating "Presets", there were generally two options:
1. current system > Every preset is defined by the bunch of settings that are modified upon activation and once activated, it "only" overwrites current active settings and has no on/off state
2. full config option > All main app settings can be saved and later restored. The app always works in any "Preset". Simply: you activate a "Preset" and live inside. All changes are automatically saved in this preset. This system is used by for example OSMAnd if I remember correctly. And this is very close to what you describe.
Both options have their advantages and disadvantages. The second option is easier to understand and offers to control all options. The first current system is limited in the number of options but offers a lot higher flexibility.
---
Rework of current system 2. to new system 1. ... uff, a major task :).
In case, most of the users will vote for the second option, I'm willing to think more about it ... 🫥
So, a current state backup which you can then quickly recall ;-)
@Konrad PM contact by the messenger in: https://forum.locusmap.eu/index.php
So, a current state backup which you can then quickly recall ;-)
@Konrad PM contact by the messenger in: https://forum.locusmap.eu/index.php
Thx for your feedback, Menion - honestly, I was struggling a bit to understand exactly what Konrad wants (I think his explanation was rather too long). Anyway, I'm quite happy with current system. Of course, if you can add the other system *additionally*, I won't complain, but not as a replacement.
However, I think one improvement would be helpful. Let's call it "Add setting to all presets".
Let's say, you add a new setting option to presets, which I want to use in one of my presets, but not the others. As it is now, I have to manually add this setting to all presets, with "default" as value in most, but with the changed value where I need it. Tedious... If it was possible to say "Add setting to all presets", I just do that and then change the preset in which i actually need that setting.
What do you think?
Thx for your feedback, Menion - honestly, I was struggling a bit to understand exactly what Konrad wants (I think his explanation was rather too long). Anyway, I'm quite happy with current system. Of course, if you can add the other system *additionally*, I won't complain, but not as a replacement.
However, I think one improvement would be helpful. Let's call it "Add setting to all presets".
Let's say, you add a new setting option to presets, which I want to use in one of my presets, but not the others. As it is now, I have to manually add this setting to all presets, with "default" as value in most, but with the changed value where I need it. Tedious... If it was possible to say "Add setting to all presets", I just do that and then change the preset in which i actually need that setting.
What do you think?
When ypu make a new preset, it copies current settings by default, but if we want to have different configuration files for complete different setups, which is what I think Konrad wants, how about we leave presets as it is ( with addition of copy to presets from Ingo)
But we add a file maagement option for the main config. I appreciate we can manually copy, restore from backup.
what I suggest is an option to save current config as filename. and load current config, and also share config.
This will leave presets, tracls and points etc intact, but allow what Konrad wants. also means easy to swop complete config, or possibly even users....
When ypu make a new preset, it copies current settings by default, but if we want to have different configuration files for complete different setups, which is what I think Konrad wants, how about we leave presets as it is ( with addition of copy to presets from Ingo)
But we add a file maagement option for the main config. I appreciate we can manually copy, restore from backup.
what I suggest is an option to save current config as filename. and load current config, and also share config.
This will leave presets, tracls and points etc intact, but allow what Konrad wants. also means easy to swop complete config, or possibly even users....
Hello Menion,
Thank you for your reply to my proposed amendment.
I haven't known Locus Map for long, but I'm enthusiastic about this program and I'm very busy with it.
A few weeks ago I started to work my way into the presets. At first I had problems because I didn't realize that the settings to be taken into account in the preset must first be specified in the second dialog and only then can the settings selected for the preset be edited in the first dialog.
The next problem was that a preset changed my basic settings, for which I had also created a preset. Each preset changed something different and I had to manually recreate some of my basic settings over and over again.
I realized that for every setting change by a preset, these settings also have to be taken into account in every other preset. You could say there is a dependency between the individual presets. What is changed in one preset must either be adopted or undone by every other preset.
Now I created a list for all possible settings that can be changed by a preset. For each of these settings, I also entered which presets use them.
Since not every setting was used by every preset, I reworked my presets so that each preset also took into account the setting changes of another preset. So I currently have a situation in which I can, for example, return to my basic settings at any time through the basic preset or have no unwanted changes in other presets.
I was happy with that. The only disadvantage of the current situation is that there are always requests to set something via a preset, which is not possible.
Well, I'm also a programmer myself and have two programs that have a dynamic base setting that is established after every start. But there is also the option of leaving the basic settings, doing something in another mode and then going back to the basic settings. I achieved all of this via a configuration backup that is called up when the program is exited, but also with every mode change.
This is the approach I was thinking of when I brought up my idea for the presets here.
I know that the complexity of Locus Map cannot be compared to my programs and cannot be evaluated by me. Of course, I see the fundamental possibility of such an approach and the associated advantages. More or less all settings could be realized via presets.
However, as a minimal solution, it should be noted in the help manual that whenever you want to go back to a defined base setting and other presets are working the way you want them to, then any setting changes made by one preset must not be ignored by other presets become.
It would be a little better to forget the second dialog for the presets, in which it is determined which settings are to be changed by a preset, and to offer all setting options equally for each preset. That would probably be the easiest to implement.
Hello Menion,
Thank you for your reply to my proposed amendment.
I haven't known Locus Map for long, but I'm enthusiastic about this program and I'm very busy with it.
A few weeks ago I started to work my way into the presets. At first I had problems because I didn't realize that the settings to be taken into account in the preset must first be specified in the second dialog and only then can the settings selected for the preset be edited in the first dialog.
The next problem was that a preset changed my basic settings, for which I had also created a preset. Each preset changed something different and I had to manually recreate some of my basic settings over and over again.
I realized that for every setting change by a preset, these settings also have to be taken into account in every other preset. You could say there is a dependency between the individual presets. What is changed in one preset must either be adopted or undone by every other preset.
Now I created a list for all possible settings that can be changed by a preset. For each of these settings, I also entered which presets use them.
Since not every setting was used by every preset, I reworked my presets so that each preset also took into account the setting changes of another preset. So I currently have a situation in which I can, for example, return to my basic settings at any time through the basic preset or have no unwanted changes in other presets.
I was happy with that. The only disadvantage of the current situation is that there are always requests to set something via a preset, which is not possible.
Well, I'm also a programmer myself and have two programs that have a dynamic base setting that is established after every start. But there is also the option of leaving the basic settings, doing something in another mode and then going back to the basic settings. I achieved all of this via a configuration backup that is called up when the program is exited, but also with every mode change.
This is the approach I was thinking of when I brought up my idea for the presets here.
I know that the complexity of Locus Map cannot be compared to my programs and cannot be evaluated by me. Of course, I see the fundamental possibility of such an approach and the associated advantages. More or less all settings could be realized via presets.
However, as a minimal solution, it should be noted in the help manual that whenever you want to go back to a defined base setting and other presets are working the way you want them to, then any setting changes made by one preset must not be ignored by other presets become.
It would be a little better to forget the second dialog for the presets, in which it is determined which settings are to be changed by a preset, and to offer all setting options equally for each preset. That would probably be the easiest to implement.
Replies have been locked on this page!