The updated version incorporates your first suggestion (thank-you for the idea). Your second suggestion (as I understand it) is a lot more difficult to implement because it would require either rewriting or duplicating all of the current Options settings code. I’m not saying that it can’t or won’t ever be done, but not for the initial release (at least not by me ).
If I compare this new functionality with the “Action Groups” of Mp3tag, I miss the possibility to move the single settings up and down. This can be very important, because you don’t want to “delete directories” before you “move the files elsewhere”,
This is how the up and down-arrows looks in Mp3tag. They work for all selected entries:
Keep in mind what you see here are not actions. There is no order of execution. It are containers that allow you to qucikly change between configurations. Yo you could have one configuration that saves and renames files without windows compatibility, one that saves and renames files with windows compatibility and one that just saves tags and does not change file. At any time you only have one option profile active.
What’s the use case. Why would you delete the directory, then move the files?
Just by error. Wrong order. Changed process flow.
Ok, just trying to understand the use case. So currently it is not possible in Picard to change the order of saving files and removing directories (which means you cannot make this mistake), and I don’t think we need this.
I’m afraid we misunderstand each other.
In the above Printscreen “Profiles Attached to…”, you see - as an example - a number 3 “Rename files” and a number 4 “Move files”.
How could I change this order to move the files first and then rename them (even if the result is the same, it’s just an example).
That are the same options as that already exist:
You cannot change the order of those actions.
The view you linked above just gives an overview which option is configured in which option profile. So e.g. you see for example that the option profile “ByeByeWin” configures both the “Windows compatibility” and the “Destination directory” option (it has some specific values for it). It does not configure other options, such as “Rename files” and “Move files” (and as no other profile configures those it means the default setting without any active profile would be used for this).
The basic idea is that you can have multiple option profiles between which you can quickly change. Let’s say you have your default settings, but sometimes you want to store the files on a external drive for your external player, and you need to have the replace non-ASCII option for that. You first would configure Picard normally. Then you add a profile that contains only the options “Destination directory”, “Replace non-ASCII characters”, “Rename files” and “Move files”. You then enable “Replace non-ASCII characters”, “Rename files” and “Move files” and set the destination directory to the external drive.
Now if you want to save on your usual local place you keep this profile disabled. But if you want to save the files for your external player you enable this specific profile, and it will overwrite the four options. Once you are done you can disable this profile again for you local tagging.
So option profiles do not have an order of operation. If you use two profiles and both enable “Rename files” it won’t rename your files twice.
What profiles have is an order of preference. You can have multiple option profiles enabled, and they all could change the same option. But profiles can be ordered, and the top one wins. E.g. for our above example you could have one profile “Save to external player”. You could add another one “Save to backup folder” that only configures a different destination directory. If you enable both it depends on the order of the profiles which folder is being used. If the “Save to backup folder” is on top then the destination will be the backup folder, if “Save to external player” is on top it will be the external player.
Actually the second option was only a possible workaround if 1. was too complicated to implement.
Setting as EAC (All options per profile) kind looks easier for basic usage but when I rode the @Zas specs I understood the logical chosen with limited options per profile was allowing more flexibility for each user so I came with the 1.
One remaining question, what is the difference between button “Restore all Defaults” and “Restore Defaults”?
PS: Process could look complicated since not able to test directly. To see when released if it generates many questions then potentially doc could be updated with an easy example. Don’t hesitate to ask me in this case
That’s already existing in current Picard. “Restore all Defaults” resets all options to their defaults (basically Picard will be configured as it was when you did a clean install without existing configuration), “Restore defaults” does this only for the options in the currently selected option section / page.