Very often presets are used to start a modules settings in the right direction. The name of the presets is automatically taken over into the ‘instance naming’ box. Great!
As soon as changed the ‘instance name’ is reset to a number. My suggestion would be to keep the presets name and add something like ‘(changed)’ or ‘(adapted)’ to it. In this way one still is able to see which preset is being used as a settings base - mostly making clear the intended use of this module instance - and at the same time it becomes clear that the preset has been adapted.
I like the proposal. Maybe prefixing the name with a symbol, e.g., * would suffice.
I don’t know how feasible this is, though. The module name is set when the preset is applied. But after applying the preset the module does not know that it has been primed with a preset, nor it knows what the values in the preset are. So, how would it decide that it should update its own title?
From the module POV the label is just a label, it has no connection with the preset. In fact, you can give a module the title of a preset even if the settings are completely different.
EDIT Ok, looking into the code base suggests that this flag is set when a module name is explicitly set by the user, which prevents the module from setting it automatically. Correct?
If (and it is a big if) I understood correctly, this is not what @Jetze is asking.
If I remember correctly: if the module has no manually applied name and its current settings match one of the presets, the name of the preset is shown.
Example: I reset exposure on a raw image, which applied the scene-referred default values, and that’s what the module’s name shows:
It is worth considering adding something to suggest it is changed, but the effort to do this may be too great for such a small reward. To hijack your thread, the improvement I would like to see to module naming is to have the export module name the preset chosen. I have mentioned this before without any luck.
I would be happy if the preset name stayed if the only thing that changed was the mask.
But I can definitely see all of this being harder than it looks at first glance. I would guess that the module settings either exactly match the preset or don’t match it at all.
How far away from the preset can the settings go before it is no longer considered the preset? Exposure is a simple example. Is +2.5EV close enough to the default +0.7EV to still be considered using the preset as a base? A module like diffuse or sharpen can get even more difficult to discern.
There are some serious problems implementing this feature. The milestone has been postponed first from 5.2 to 5.4, now to version 5.6. I wouldn’t be overly optimistic, comment from @zisoft on February 24, 2025 :
[…] but I must admit that I’m thinking about giving up […]
else if(strlen(module->multi_name) > strspn(module->multi_name, "0123456789"))
{
if(module->multi_name[0] != '*')
{
// prepend asterisk to indicate changed from preset
int len = MIN(strlen(module->multi_name), sizeof(module->multi_name) - 2);
memmove(module->multi_name + 1, module->multi_name, len);
module->multi_name[0] = '*';
module->multi_name[len + 1] = '\0';
}
}
Issues to be fixed with this approach:
Empty multi_name when resetting all module params. And maybe in some other cases.
For built-in presets, the leading * gets concatenated to the string translation markers. If “*” is what is decided on, the segmented name translation routine needs to know to give it special treatment.
Only one * is added; if someone already starts their preset names with * then nothing will happen
I have created various presets for saving JPG, Tiff, and PNG outputs. I would like to just glance at the export module header and be assured which preset I have set. At the moment I have to expand the export module to know for sure which export settings I have. This has nothing to do with export styles as I never apply a style upon export. The practicality of implementing what I suggest I have no idea about. I have just made the suggestion and if it is practical and some developer feels it is worth their time to implement it then that is great.
