DeaDBeeF-Player / deadbeef

DeaDBeeF Player
https://deadbeef.sourceforge.io/
Other
1.64k stars 178 forks source link

[Feature Request] Expanded view of multi-value tag fields #2116

Open mallniya opened 5 years ago

mallniya commented 5 years ago

At first -- good to see deadbeef updated, thank you for hard work and dedication. As of 1.8.0 update there is no more than 1 line of multi-value tag fields showed in "Selection properties" (only first line and "(...)"), which is really sad for me, because I use it heavily and seeing all the information about track is really handy and nice. Could you please at least make pre 1.8.0 multi-line look optional? Thanks.

Oleksiy-Yakovenko commented 5 years ago

There were reasons to remove the expanded view.. It worked on GTK2, and early versions of GTK3, but the later GTK3 regressed and broke the feature. Then the devs ignored the bug report for a few years, so I didn't have other choice than to remove this.

I already have notes about how to re-implement the fields like comments and lyrics as separate tabs in track properties, but return to expanded table view cells is unlikely to happen.

There's also slight confusion in your issue description.. These fields are not multi-value, they're simply multiline. That's 2 different things. Multiple values are displayed on the same line, separated with semicolon.

RobertZenz commented 5 years ago

It worked on GTK2, and early versions of GTK3, but the later GTK3 regressed and broke the feature.

Having it configurable with only the GTK2 plugin isn't an option for you?

I already have notes about how to re-implement the fields like comments and lyrics as separate tabs in track properties, but return to expanded table view cells is unlikely to happen.

Maybe it would be easier to give us a single control which displays the value of a given tag as simple text, or maybe even of a format string (not sure what it is called) as it is already used in many other places. That way we could put it on the UI as we would see fit and multiline values would simply be a multiline label. I'd actually prefer that solution, as it would give me a lot of flexibility (and to be honest, I don't care much about the metadata display, so I could have two tabs in its place, one tab with the lyrics and one tab with the metadata viewer).

Thinking about it a little more, and if that control has an option to toggle between "currently playing" and "currently selected" it would be golden.

mallniya commented 5 years ago

There's also slight confusion in your issue description.. These fields are not multi-value, they're simply multiline. That's 2 different things. Multiple values are displayed on the same line, separated with semicolon.

Yes, I'm confused:

$ vorbiscomment -l downloads/test/test.ogg 
TITLE=test
COMPOSER=first
second
$ metaflac --export-tags-to=- downloads/test/test.flac 
TITLE=test
COMPOSER=first
COMPOSER=second

Both files was edited the same way: COMPOSER was filled with ctrl+enter between first and second. Is this makes the same actions in tag editor creating different types of tags? Because for me with ogg it's multiline, and with flac it's multivalue.

All I wanted to say is that now displaying and editing this tags for flac (#2163) is broken. Also behavior of editor became unpredictable: for flac you create tags with ctrl+enter and deadbeef shows them like first (...), but after "Reload metadata" action on this track it becomes first; second (metaflac shows no changes after reloading).

mallniya commented 5 years ago

After #2163 I'm pretty sure I meant multivalue tags. Now same actions lead to the same desired results:

$ vorbiscomment -l downloads/test/test.ogg 
TITLE=test
COMPOSER=first
second
$ metaflac --export-tags-to=- downloads/test/test.flac 
TITLE=test
COMPOSER=first
second

Which is really nice, thanks a lot. But first (...) look in "Track properties" still confusing. Also notice, that in search window multivalue tags is displayed as first_second -- which is inconsistent with "Track properties".

Oleksiy-Yakovenko commented 5 years ago

But first (...) look in "Track properties" still confusing.

It indicates that there's more text which can't be displayed on a single line. I didn't reinvent a wheel here, and used the same appearance as Foobar2000.

Also notice, that in search window multivalue tags is displayed as first_second -- which is inconsistent with "Track properties".

Unlike playlist view, track properties view is not using title formatting, and they're not supposed to be consistent with each other.

Replacing linebreaks with underscores works by design, it matches Foobar2000 behavior, and I'm pretty sure it's covered by some part of title formatting spec, but I couldn't find a specific place.