I think I got it. I had to refactor the Watch table to be view-based instead of cell-based, and various other tweaks. Also, need to localize the two columns. I suppose I/someone could actually just use "Name" and "Value" and copy all the localizations from theSettings > Advanced table...

[Edit: saw a color regression in previous commit; pushed another quick update to fix.]

First issue. Us programmers are used to "property key". Not sure the public is. When you add something to the table the IINA prompt asks for mpv property name. So I don't think the name of the first column should be Key. Since we use Name for the column that contains the option in Advanced settings, I'm thinking that is the correct choice. The other choice would be Property.

Changed to Name.

Second issue. When the window first came up the column containing the property was small and truncating the names despite all the space we have to work with. When possible the columns should be initially sized appropriately.

I added a bit more default width to the Name column. I'm just not sure too much extra space will be needed in most cases, because all the property names I came up with could easily fit, although I'm not at all an expert in mpv properties and their values. At least the column widths will be remembered across launches.

Also, I think the actual width of the window will vary depending on the length of some of the fields. Edit: Looks like this can't really be avoided without allowing text to wrap...

Third issue. Resizing the first column introduced a scroll bar, which seems odd given the values in the table are so small compared to the available space

I think I fixed it - please confirm.

Also:

1. I found a case where the new code could crash at quit due to a call to mpv.getString(). Added the appropriate checks.
2. Added localizations for Name and Value column headers by copying the strings from the Advanced tab. Also localized the "<Error>" message by copying the strings from "alert.title_error" in Localizable.strings. But I thought that leaving the brackets around it looked kind of weird when viewed with Asian hieroglyphs, so I swapped the brackets for an italic & grayed style.

The latest commit seems to have fixed my concerns. For some reason the table seems to be messing up the cursor shown when changing column width. Not sure what is causing that. My guess is the other reviewers will not like the changes to the localization files. The usual issue with disrupting Crowdin automation.

My guess is the other reviewers will not like the changes to the localization files. The usual issue with disrupting Crowdin automation.

I'm fine with backing out the localizations if needed. That took a lot less time than the other parts.

For some reason the table seems to be messing up the cursor shown when changing column width.

Do you mean that it's a resizeLeft cursor instead of resizeLeftRight?

...OK, so I was halfway into a detailed analysis, but then I followed a hunch and discovered that the problem looks like a bug in Apple's new "Full Width" table style. It is fixed by setting the table's style to "Automatic" instead (...although the resize cursor is still not 100% right...it's less obviously wrong. I don't think we can expect too much from NSTableView, tbh ✌️)

Posting the remainder for posterity!

I've set the Name column resizing mode to User Resizable, and the Value column to Autoresizes with Table, and set the table's columnAutoResizingStyle to Last Column Only. Then I set the Value column's width so that its right side is hugging the right side of the table.

When configured like this, the Value column "snaps" to the right edge, and the result is that the Name column will only resize via the user's drag of item 1 below, while the Value column will only resize when the window resizes. You should see the vertical line at the right of the column header (2) move as the window resizes.

If instead I were to make both columns User Resizable or Both, the second column will need the user to resize it manually:

For research, I went to see what Apple does with Finder, so I tried playing with its List View and putting the Size/Date Modified columns up against the right edge of a Finder window. It looks like they are configured as Both, and also have maximum sizes. But there seems to be other weird logic that Apple is using, and to be honest I don't understand why I sometimes can resize the second-to-rightmost column and sometimes can't. So that has not been helpful.

With style Automatic. Main difference seems to be more horizontal padding in parts of the header. But the cursor is fixed.

Argh. I now see visual artifacts with style Automatic... Perhaps I should just change the second column to User Resizable...?

Mostly I wanted to make sure the oddity with the cursor was AppKit and not something we were doing. Seems to me some AppKit programmer was lazy and did not properly use the resizing cursors.

I have always thought tables should look is shown with Autoresizes with Table. That 3^rd empty column seems super odd to me. But it seems to match up with other IINA tables. I performed the following test twice cause I didn't expect the answer and thought I must have messed up…

I brought this over to my MacBook Air running Catalina and the behavior changed. Under Catalina the table acts and looks just like what is shown above with Autoresizes with Table. Isn't that interesting.

On <Error>, I always disliked that. I like switching to dimming. I think that is fine for now, but really a proper error message is required. A future task.

Thumbs up from me for the changes as is, BUT I am certain the PR will be rejected due to including the translation files for other languages. They have gotten serious about that.

I have not forgotten about the base/en issue and how the en translation files are not needed. People have been busy with the current release. 1.3.3 just got released. At some point soon attention will move to the next release which is planned to be the feature release that has been talked about for some time.

So, couple things...

@low-batt was hard to tell if you were endorsing the Fulll-Width style or Automatic. I prefer the Full-Width, despite the cursor oddity.

There is another, more serious problem which I discovered, and I made several pushes thinking I had fixed it (and also other things), only to ultimately have to admit defeat and roll back, having run out of time...

There's a problem coming from the translucent background for the table. There are color glitches. It only presents itself if once you try to horizontally scroll. The background of the header suddenly brightens. It looks even worse if you then resize the window:

If I clear out the table background and show just the header, like this, the problems are gone. But not sure if it is the desired look, and it visually separates the table from the +/- buttons.

I liked the one where the Value column "snaps" to the right edge.

For the latest issues you brought up I have to defer to the other developers. I too am unsure what they would prefer.

Much soul-draining trial & error later, I have found solutions & workarounds.

I was able to get a bug-free translucent background by enclosing the table inside a container view, and adding a translucent background to that. Hooray.

I also made some progress on figuring out the arcane way column sizing is done. I was able to make the Name column reduce itself in width when the window is resized, so the Value column won't get hidden.

Also added animations when inserting & deleting rows (respecting the "Reduce Motion" pref) - was not hard and looks nice.

Lastly I discovered another problem caused by using translucent headers. If there are enough entries and the table starts to scroll down, NSTableView will draw rows overlapping the header as noted here and here. I think it's safe to say NSTableView doesn't support scrolling a table with a translucent header. So I added a workaround which will make the window taller as more rows are added, so that the table will not scroll. Don't expect this will be a problem for the vast majority as I can easily fit 25+ properties just on my MacBook's 16" screen.

The new look of the TableView is cool! I just tried by rebasing the branch to develop. Just a small thing to add, could you make the TableView multiple selection? It would be convenient to remove multiple entries.

Just a small thing to add, could you make the TableView multiple selection? It would be convenient to remove multiple entries.

Done - take a look at the latest commit.