REQUEST: Extended Tags upgrade

So we have the Extended Tags icon that comes handy when we want to see all of the tag fields used- and not just those that we know of. Extended Tags also mandatory tries to show us the attached cover

How about data like %_file_mod_date%?

Normally I have this shown constantly as a column. But when I need that extra space for a while then I turn it off- but then again I have to sometimes turn it back on for a moment just to check out the date / time; and once again turn if off to gain the horizontal space. And so right now I have to do this via Customize columns, which adds to just way too many clicks [4 + 4]. If the Extended Tags window would show this, then it would take me only a quarter of this [1 + 1]

The extended tags dialogue shows you the tags that can be modified by MP3tag.
The modification date is modified by the OS.

OK, point taken

But I still would like to be able to see than data in the Extended Tags field

And another big request would be to make it possible for Mp3tag to also change that data: /t/19764/1

So for now I wish I would see that parameter in there even if it would remain non-editable; and in the future if that kind of data would become editable in Mp3tag, your point would no longer be the explanation of why this data cannot be shown there

Have a look at the list of information fields: https://docs.mp3tag.de/export
The list stretches over more than one screen on my PC - and I bet that once you add one non-editable field to the extended tags dialogue, you have to add them all. Which then makes the dialogue very long and you would have to scroll a lot.
As soon as you select more than one file in the files list and use the extended tags dialogue, a lot of these fields will turn to (or as this has to be different from the editable fields) as there will be very few files that have really been created at the very same moment. The additional information then becomes more or less useless in my opinion.
I find it quite useful to see that information in the files list as there it is clear that these are the properties of that single specific file.

I am not the programmer. So it could well be that your suggestion becomes part of the program. Me, personally, I do not see any benefit, on the contrary, for me a dialogue with a clear purpose would become congested with most of the time useless information.

That could be a workaround: writing an export action that would show me that kind of data. So that would leave me with how may steps?:

1] CTRL + E

2] Selecting of a proper export from the list

3] Confirming to "Display export file now"

4] Closing of the text file

So that adds up 100% more than what I am advocating for - and 50% less to what I currently have to perform. But on the down side it I would also not be able to utilize the navigation feature through files with the < < and > > buttons

How about "can" and not "have"? Does you Tag Panel display constantly all of the tag fields that you use; or all of the tag fields that are defined in the ID3v2 standard?; or used by iTunes?

As long as those are not editable, this should remain an option. And it would be up to user what data to display

And in the wake of this thread /t/19753/1, all of that I am talking about could be implemented not under in the Extended Tags but as data displayed somewhere else [also user defined. All in all there is a lot of unused space all over the whole window of Mp3tag

But most of the time I need to check one file

And I if do select more than one file, I think I will remember what seeing means

For me it is vital

And I am describing here situation where I turn of my vital column for some relatively short time, during which I need unfortunately to turn in back on for a moment [which now is a 8 step task] and possibly repeat that on and off shebang multiple times during a work session- and the Extended Tags icon is right there, ready to be upgraded with more info [for those who need it]

I was not talking about a workaround - I was referring to the longish list of attributes that could also be of interest - perhaps not for you but for other users.

You depict a special workflow where your idea might lead to a little advantage while other workflows do not benefit from it, on the contrary, they might even come off worse.

As I said: I am not the programmer. So it could well be that the future will bring a user-definable extended tags dialogue.

As I said: an option co configure Extended Tags window. With a button to reset to default settings for those users who will mess up

We can configure Columns however we like and we can configure Tag Panel [almost] however we like. So why not Extended Tags?

Yes and this is the basic difference: YOU have to CONFIGURE (sorry for capitals) - whereas the extended tags dialogue configures itself and shows you all the tags that are worth the purpose of the MP3tag tag editor: they can be edited.
The tag panels is fixed and does not show more or fewer fields depending on the data in the loaded files.
The number of columns is fixed and does not vary depending on the data in the loaded files.
But the extended tags shows you all the editable tag fields that can be found in a file, so the list of fields varies.

Also, it is the only place where you see multivalue fields (unless you have defined the values in such a fashion in the columns setup - which not everybody does) which is an enormous help for a deeper insight while dealing with questions of users in this forum.

I interpret the differences in the user concept as intended and probably proven - as the trinity of tag panel, file list and extended tags dialogue offers different levels of submerging yourself in the properties of a file.

And as with all the suggestions: in the end it is the programmer who decides what gets implemented. But if he asked me what to do first: expand the extended tags dialogue or implement some more database functions, I would definitely favour the improvment of the database functions as I can already easily arrange the columns and the extended tags dialogue in such a way that I also see the read-only fields if I should need to read them.