Fixed Frame != Bounds; changed UICat Scenarios list to use tableview!

[tig]

Instead of a bunch of comments in code-review I decided to fix things by writing code.

• TV had some "Bounds != Frame" bugs latent since the move to the new View architecture. Fixed (with one TODO having to do with How should MouseEvent work with Margin, Border, and Padding? gui-cs/Terminal.Gui#2578)
• Updated UI Catalog to use TableView for the scenarios list instead of ListView. There's no reason to do this, really, other than an exercise in exercising TableView more ;-).

Things I learned:

• Getting column widths to work the way I want was confusing. I finally figured out I had to do all this, which is I don't fully undersatnd:

var longestName = _scenarios!.Max (s => s.GetName ().Length);
ScenarioList.Style.ColumnStyles.Add (0, new ColumnStyle () { MaxWidth = longestName, MinWidth = longestName, MinAcceptableWidth = longestName });
ScenarioList.Style.ColumnStyles.Add (1, new ColumnStyle () {  MaxWidth = 1 });

This gets me "1st Column is fixed at maximum width of scenario names and 2nd Column fills rest of view". But the code certinly doesn't say that. What I expected to work:

var longestName = _scenarios!.Max (s => s.GetName ().Length);
ScenarioList.Style.ColumnStyles.Add (0, new ColumnStyle () { Width = longestName });

• TableView really needs to leverage LineCanvas. As soon as it does, it will be trivial to always draw the header lines (etc) +1 bigger on each side. If it uses tableView.LineCanvas when it does, autojoin with the border will just work!

That said, i think the header in UI Catalog is overkill and I don't actually think we should leave it in. But i have it enabled so we don't forget about this...

[tznind]

Awesome! Looking really nice.

I finally figured out I had to do all this, which is I don't fully undersatnd

Sizing in TableView is done at render time. The goal of the process is to start drawing from a given offset (row/col) and size based on user constraints (ColumnStyle) and the size of data in the next y rows (where y is the console height). This means that TableView doesn't need to examine all the data in the table to work out sizes (which could be slow in some situations and/or inaccurate where table data changes in realtime).

I agree its very overkill for situations like this where theres only 20 or so items and user ends up having to measure their own data. I wonder if there is a solution like SizeColumnsToAllData or something that would simplify things for this use case.

TableView really needs to leverage LineCanvas. As soon as it does, it will be trivial to always draw the header lines (etc) +1 bigger on each side. If it uses tableView.LineCanvas when it does, autojoin with the border will just work!

Yup definetly, this is on my todo list!

Actually looks like this is already underway: gui-cs#2574 ❤️