New terminal text for track descriptors is too wide and wastes space, additionally includes non-ascii characters

mlindner commented 3 weeks ago

mpv Information

mpv v0.38.0-582-ge8e6e91c49-dirty Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Jul  8 2024 14:19:51
libplacebo version: v7.349.0
FFmpeg version: n7.0.1
FFmpeg library versions:
   libavcodec      61.3.100
   libavdevice     61.1.100
   libavfilter     10.1.100
   libavformat     61.1.100
   libavutil       59.8.100
   libswresample   5.1.100
   libswscale      8.1.100

Other Information

Linux version: Arch Linux Kernel Version: Linux archHTPC 6.9.8-arch1-1 https://github.com/mpv-player/mpv/pull/1 SMP PREEMPT_DYNAMIC Fri, 05 Jul 2024 22:11:24 +0000 x86_64 GNU/Linux GPU Model: 1f:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [Geforce RTX 3050] [10de:2507] (rev a1) Mesa/GPU Driver Version: Window Manager and Version: Source mpv: self-built Introduced in version: d49879f

Reproduction Steps

Play any file and observe that the terminal track info listing has gotten significantly larger with wasted space. The text used to be relatively succinct with narrow text that was easy to read at a glance. Now it's gotten significantly larger with information that isn't useful. It additionally includes non-ascii characters that don't render the same in all fonts, especially in cjk fonts.

For example we do not need a massive [default] at the end of every single track. Which track is default is self evident the moment the file is loaded because the defaults are what are selected.

Nor do we need a whole ton of white space padding. around each track line. There was already padding out to the width of the words Audio Video and Subs to 6 characters, now it has been expanded to 7 for inexplicable reasons. There does not need to be two characters between --aid=1 and --alang=jpn, nor does a bunch of white space need to be added between --vid=1 and the track descriptor.

Depending on the font the ● character can be very wide and blobby. It looks significantly different from my Mac OS system to my Linux system depending on the text it is in (for example in this web form it is a very huge white circle, not a radio button-looking character).

Expected Behavior

Succinct text like used to be:

 (+) Video --vid=1 (*) (h264 1280x714 23.976fps)
 (+) Audio --aid=1 --alang=jpn (*) (flac 2ch 48000Hz)
 (+) Subs  --sid=1 (*) (ass)

Actual Behavior

Very wide text like including non-ascii characters:

 ● Video  --vid=1               (h264 1280x714 23.976 fps) [default]
 ● Audio  --aid=1  --alang=jpn  (flac 2ch 48000 Hz) [default]
 ● Subs   --sid=1               (ass) [default]

Log File

Log file not needed for this.

Changes were made in: https://github.com/mpv-player/mpv/pull/14405 https://github.com/mpv-player/mpv/pull/14192

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

[X] I tested with the latest mpv version to validate that the issue is not already fixed.
[X] I provided all required information including system and mpv version.
[X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
[X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
[X] I attached the full, untruncated log file.
[X] I attached the backtrace in the case of a crash.

kasper93 commented 3 weeks ago

Play any file and observe that the terminal track info listing has gotten significantly larger with wasted space.

Unused space is wasted too. It is well under 80 columns in most cases, which is reasonable width.

Now it's gotten significantly larger with information that isn't useful.

Arguable, what information is new compared to before and not useful?

For example we do not need a massive [default] at the end of every single track. Which track is default is self evident the moment the file is loaded because the defaults are what are selected.

Not true, there can be multiple default tracks, and this is more readable than (*) which no one knew what it means, or [F] or few others random characters that are understandably only after reading the code. As an exercise tell me what [P] meant before?

Nor do we need a whole ton of white space padding.

Whitespaces alignment makes it more readable. Putting mix of everything into single not separated line is no better.

Depending on the font the ● character can be very wide and blobby. It looks significantly different from my Mac OS system to my Linux system depending on the text it is in (for example in this web form it is a very huge white circle, not a radio button-looking character).

This is valid point and has been raised before, not sure why we settled back on ● after all.

mlindner commented 2 weeks ago

Unused space is wasted too. It is well under 80 columns in most cases, which is reasonable width.

Unused space at the end doesn't wrap the line making it harder to read. Lines that didn't wrap before are now wrapping on my setup when I tile my terminal.

Not true, there can be multiple default tracks, and this is more readable than (*) which no one knew what it means, or [F] or few others random characters that are understandably only after reading the code. As an exercise tell me what [P] meant before?

When heave you ever found that information useful though? In the two decades I've been using mplayer and then mpv I've never used any info about default or forced tracks (heck I don't even know or care what a "forced" track is). It wasn't even there several years ago. It got shoved in by somebody as those asterisks at some point. As you say no one knew what they meant, so it wasn't serving anyone anyway, just remove them.

Whitespaces alignment makes it more readable. Putting mix of everything into single not separated line is no better.

Whitespace alignment makes it more "pretty". Readability is debatable. I never had problems reading it. It's not that much text. And there's more whitespace being added than just that for alignment. You don't need two spaces between each section. As you can see, there was already white space for alignment for the first part.

The way I see it, at the minimum we can cut out 3 spaces of completely extraneous whitespace, remove the [default] that no one ever used because they didn't know what it meant, (or at least shorten it to def or something), and add an option to remove alignment if people don't want it.

Dudemanguy commented 2 weeks ago

When heave you ever found that information useful though?

Pretty often when I want to check at just a glance to make sure the correct track was selected.

mpv-player / mpv