[Feature]: Playlist like view

[sandersantema]

I'd like to use a playlist based view instead of filesystem based. To illustrate what I mean:

Filesystem based:

Playlist based:

What's of importance here is not for instance the metadata displayed, a filename such as seen in the filesystem based view should be sufficient. What is however the use case for this playlist based view is that I often like to edit the metadata of newly imported songs or for instance all songs without a genre. I can filter for these criteria and then select these songs in my music player after which I'd like to edit their metadata in the order of selection.

[Martchus]

Sounds like a lot of effort to implement. Currently, the tag editor's GUI has no internal database/index which could be easily queried to implement the filtering.

I'll keep this as a valid feature request but I'm not sure whether I'll be working on this feature any time soon. Contributions are welcome of course.

With such a view implemented, the GUI would basically be half a media player. Only the actual playback would be missing (which would likely be rather simple to implement, e.g. using Qt Multimedia).

This leads to an alternative idea: Maybe there's a Qt-based media player which already provides a similar view with filtering? It might be possible to incorporate the TagEditorWidget there. That approach could solve the problem from a different angle.

[sandersantema]

Although I'd like to have the functions you described I meant for the scope of my feature request to be a bit more modest. I for instance currently use a workaround where I symlink a selection of file paths to a single folder. This already does what I want it to although a lot more refinements are possible.

[Martchus]

Ok, so it wouldn't be the tag editor which computes the files to be shown in the view (based on some filtering/search criteria) but the user would actually add files to the view manually. That would be easier to implement (but also less useful).

Since you've mentioned that you're using symlinks: I have actually never thought one would do that. It could be that this isn't working very well in the case the tag editor needs to rewrite the file because then it would rename the original file and create a new file (copying data from the renamed original file applying tag modifications). I guess the new file would then be created only in the directory where the symlink is located but the symlink target remains unaffected. That's likely something I should improve because I suppose the desired behavior is to modify the symlink target in any case.