PICARD-2025: Add file path to metadatabox

[zytact]

Summary

• This is a…
  • Bug fix
  • Feature addition
  • Refactoring
  • Minor / simple change (like a typo)
  • Other

Problem

Adding File Path to metadata view

• JIRA ticket (optional): PICARD-2025
• JIRA ticket to update documentation: PICARD-3017

Solution

Add a Path tag in the metadatabox for a single file (for efficiency reasons) with original value from file.filename, new value from file.make_filename only when move_files or rename_files is enabled.

[phw]

Thanks. This is one of those cases where the more we talked about it the simpler the code changes became :D

Looks good to me except for some minor stylistic comment and making the name translatable. I think otherwise this change does what we need.

But I'd like to test run this to see whether it does what we need. I'll need to leave in a few minutes, so will look at this later again.

Also let's see what others have to say.

[zytact]

Thanks. This is one of those cases where the more we talked about it the simpler the code changes became :D

Looks good to me except for some minor stylistic comment and making the name translatable. I think otherwise this change does what we need.

But I'd like to test run this to see whether it does what we need. I'll need to leave in a few minutes, so will look at this later again.

Also let's see what others have to say.

Yes, it did seem daunting at first. Thank you for the patience you and everyone else showed. I am still fairly new to this codebase and to contributing to open source.

[Sophist-UK]

Can we please stop using force push?

[rdswift]

A couple of things...

1. Can you please make sure that there is also a ticket to update the Picard documentation, and note the ticket in PICARD-2025 and here so that it doesn't get lost? Thanks.

2. Does there need to be some way to update the new value automatically whenever one of the other new tag values is changed (because the tag value being updated may be used in the renaming script?

[Sophist-UK]

@rdswift Bob - you make a very good point about updating the file path when any metadata used in the file naming script gets changed.

Also, we need to be mindful of the metadata summarisation and check that this works correctly. And for this I think that the path and file name should probably be shown separately - so that e.g. if you select all the tracks in an album, then you can see that the path is the same, but the filenames are different.

[phw]

Does there need to be some way to update the new value automatically whenever one of the other new tag values is changed (because the tag value being updated may be used in the renaming script?

That's a good point. I tested, and this is already happening.

But a separate thing is that the metadata view now also should update if file naming options are changed (all of rename files, move files, the selected script or the script itself). Not sure how to best do this, we currently don't have a good generic solution for this. Some option dialogs trigger UI updates explicitly for their changes. But the file naming options can be toggled in multiple places (file naming options, script editor dialog, options menu quick settings).

Also, we need to be mindful of the metadata summarisation and check that this works correctly. And for this I think that the path and file name should probably be shown separately - so that e.g. if you select all the tracks in an album, then you can see that the path is the same, but the filenames are different.

I asked @zytact to implement this only for single files selected. I don't think running the script on a huge number of files is a good idea. We already need to be careful with metadatabox updates if multiple files are selected. It's also seldom useful, as every file loaded has a different path.

If this is a wanted feature this can be addressed separately, but it will be significantly more complicated. We could for example pre-calculate the path for all files and update it in the background if it changes for any

[phw]

Tested this and I have a few more comments, see below.

Also the new row is not properly readonly, setting the flag on the TagDiff.add call is currently not enough. There is some special handling for ~length in

picard/picard/ui/metadatabox.py

Lines 713 to 714 in 4fefe6c

	if tag == '~length':
	new_item.setFlags(orig_flags)

, which makes sure the field does not get the Qt.ItemFlag.ItemIsEditable set.

We can improve this. My suggestion is to add a new helper method to TagDiff to check the readonly state of a tag:

class TagDiff:
    # ...

    def is_readonly(self, tag):
        return bool(self.status[tag] & TagStatus.READONLY)

Then use this in

picard/picard/ui/metadatabox.py

Lines 713 to 714 in 4fefe6c

	if tag == '~length':
	new_item.setFlags(orig_flags)

                if self.tag_diff.is_readonly(tag):
                    new_item.setFlags(orig_flags)

[zytact]

Does this work?

[rdswift]

But a separate thing is that the metadata view now also should update if file naming options are changed (all of rename files, move files, the selected script or the script itself). Not sure how to best do this, we currently don't have a good generic solution for this. Some option dialogs trigger UI updates explicitly for their changes. But the file naming options can be toggled in multiple places (file naming options, script editor dialog, options menu quick settings).

Maybe we can detect this in the module that actually updates the settings and emit a signal from there? All the (related) changes from the various locations all pass through this module (including changes to the enabled profiles), so this might be a simple way to catch them.

picard/picard/config.py

Lines 192 to 201 in 241aa66

	def __setitem__(self, name, value):
	# Don't process settings that are not profile-specific
	if name in profile_groups_all_settings():
	for profile_id, settings in self._get_active_profile_settings():
	if name in settings:
	self._save_profile_setting(profile_id, name, value)
	return
	key = self.key(name)
	self.__qt_config.setValue(key, value)
	self._memoization[key].dirty = True

We could create a set containing the settings that would trigger a change to the file naming behavior and emit a signal if the setting being changed was contained in the set. The suggested settings to trigger the signal might include: "enabled_plugins", "move_files", "move_files_to", "rename_files", "standardize_artists", "va_name", "windows_compatibility", "selected_file_naming_script_id", "file_naming_scripts", "user_profiles" and "user_profile_settings".

[phw]

@zytact Your newest changes look good to me. What we could do is to wait for rdswift's changes from #2567 to be merged, then the metadatabox could also implement listening to config changes and run an update if file naming related options change.

[zytact]

@zytact Your newest changes look good to me. What we could do is to wait for rdswift's changes from #2567 to be merged, then the metadatabox could also implement listening to config changes and run an update if file naming related options change.

Of course.

[zas]

@zytact Your newest changes look good to me. What we could do is to wait for rdswift's changes from #2567 to be merged, then the metadatabox could also implement listening to config changes and run an update if file naming related options change.

Of course.

#2567 was merged

[zytact]

Is this what we are looking for?

[rdswift]

Is this what we are looking for?

I think @phw was also looking for a way to indicate that the path and filename need to be recalculated if any of the settings that impact the file naming have changed. Settings like: "enabled_plugins", "move_files", "move_files_to", "rename_files", "standardize_artists", "va_name", "windows_compatibility", "selected_file_naming_script_id", "file_naming_scripts", "user_profiles" and "user_profile_settings". Note that some of these may not impact the file renaming, but they could.

[zytact]

Is this what we are looking for?

I think @phw was also looking for a way to indicate that the path and filename need to be recalculated if any of the settings that impact the file naming have changed. Settings like: "enabled_plugins", "move_files", "move_files_to", "rename_files", "standardize_artists", "va_name", "windows_compatibility", "selected_file_naming_script_id", "file_naming_scripts", "user_profiles" and "user_profile_settings". Note that some of these may not impact the file renaming, but they could.

I see. OK. I'll do that.

[phw]

Is this what we are looking for?

Yes, but rdswift compiled a much more complete list of setting keys that might affect it.

[phw]

Thanks a lot. Works great for me. Let's merge this.

[zytact]

Thanks for helping me and the all the patience. 🙂