At File > Options > Export you can tick "Append data" and "One file per directory". These settings directly correlates to the same ones at File > Export, because if you change them at either place they'll stick at both.
However, at Actions > Export the pre-settings are always un-ticked, so they don't correlate to the settings at File > Options > Export. And, in contrast, if you tick them they don't stick.
These differing approaches is a bit confusing to me, since I would expect my settings at File > Options > Export to stick permanently, and also be consistent at all dialogues. If I temporarily want to change a setting for a specific export, it shouldn't affect my general settings.
Any thoughts on this, and is there a (technical) reason for this inconsistent behaviour?
If you execute an action more or less blindly, possibly even as part of an action group with many actions, then I think it is much more straightforward to use the settings once set when creating and testing this action.
The settings seen in the dialogues and user interaction are kept as MP3tag treats the user input as set - a concept that is also followed in the actions: the user has set it accordingly, so keep it.
E.g. while the quick action "Replace" shows the settings from the last call, the same action in an action group would always use the settings as saved on creation.
File > Export: Ticking sticks
Quick Actions > Export: Ticking does not stick
Quick Actions > Replace: Ticking sticks
Yes, since you refer to the settings in the mta file. Then there are 3 cases to consider:
Quick Actions > Replace: Ticking sticks
Action Group > New > Replace: Ticking does not stick
Action Group > Edit > Replace [existing action]: Ticking sticks, but only because it's saved in the mta file for that action group
Saved actions in action groups is not what I'm concerned about, naturally they need their own, fixed case-by-case settings. It's the other tick-saving that could be more consistent.
As it is now, "Append data" and "One file per directory" at File > Options > Export seems redundant in the current implementation. I think either make them master settings or remove them would make more sense.
It is consistent if you take the user-interaction as common grouping element:
are used in an interactive situation.
is interactive (again), you see the dialogue and can adapt it according to the current requirements.
Creating an action group always starts with an empty action group and you have to set each action from scratch.
But this is not what I referred to: if you call an existing action group you do not see the individual settings for each action in that group but the group gets executed as set. This leaves no traces in respect to other groups or actions - which I think is the desired and expected behaviour.
As you started the thread with an observation at the export function:
is the interactive situation, in which you can adapt the settings to the current requirements (or simply click OK)
is no dialogue situation but takes the settings as once defined and probably found to be the right ones for this action task.
You asked for the
The reason is: different context in the user-interaction.
And IMHO it is not inconsistent.
User interaction and dialogues don't make it consistent just because they exist. The inconsistency lies in the differing pre-settings across the dialogues. Consider these scenarios:
You want to make an export, so you go to File > Export. You get a dialogue where "Append data" and "One file per directory" are pre-ticked because that's what you had used the last time.
You want to make the same export, but instead go to Actions (Quick) > Export. You get the same dialogue but nothing is pre-ticked, because there it never is.
The two dialogues look exactly the same but the user interaction would be different, since the pre-ticking is different. That's not consistent.
So
is a misconception because in the two examples above the context is the same, and the user had the same user interaction in mind - but it wasn't possible due to seemingly identical dialogues with differing pre-settings.
Agreed, but action groups are a side case here, where it's also fine that no input settings are saved, as it suits the purpose there.
What's interesting though, is that the quick actions always saves the user input to the next occasion - except for the export action, which happens to be the topic here. That's odd, what could be the reason?
Would a reason really help to forward this topic? (Rhethorical question)
You already got several possible reasons and apparently you do not accept them.
So, you told aus about an observation and your opinion that you do not like that behaviour. Noted.
But anything further?
The functions work, the user has to decide anew every time which settings are best for the current situation, so it does not really matter whether with which settings the dialogue situation starts, IMHO.
You think different.
If the current behaviour should get changed I wonder what the reply should be for queries why the familiar behaviour is now different.
I think that you have clearly described your qualms. What will happen next has to be decided elsewhere.
Yes, if it has something to do with the inconsistent behaviour across the dialogues. That's also why I asked "is there a (technical) reason" in my first post. But, of course, I could have been clearer in my last post.
We do think differently. I prefer to have pre-settings one way or the other, not in various ways.
Again, thanks for your input . It has helped me understand that as long as the behaviour is consistent, there are two (potentional) solutions that would do the trick (for me at least):
• The settings at File > Options > Export could be made master settings, so that ticking/unticking in the export dialogues always would be temporary and wouldn't stick
• "Append data" and "One file per directory" at File > Options > Export could be removed, since they currently fill no purpose there (since they will be altered at File > Export)
In the 2nd case, it would be preferable (but not necessary) if the settings at Actions (Quick) > Export also would stick (just like the other quick actions), but perhaps there's a technical reason why they currently won't.
