Update based on edited question:
First, just so you're aware, NSTableCellView
is not an NSCell
nor a subclass of it. When you are using a view-based table, you are not using NSCell
for the cell views.
Also, a view's frame
is always relative to the bounds of its immediate superview. It's not an absolute position. And the superview of the cell view is not the table view nor the scroll view. Cell views are inside of row views. That's why your cell view's origin is at 0, 0.
You could use NSTableView
's frameOfCell(atColumn:row:)
to determine where a given cell view is within the table view. I still don't think this is a good approach, though. Please see the last paragraph of my original answer, below:
Original answer:
Table views do not "contain" a bunch of NSCell
s as you seem to think. Also, NSCell
s do not have a position. The whole point of NSCell
-based compound views is that they're much lighter-weight than an architecture that uses a separate object for each cell.
Usually, there's one NSCell
for each table column. When the table view needs to draw the cells within a column, it configures that column's NSCell
with the data for one cell and tells it to draw at that cell's position. Then, it configures that same NSCell
with the data for the next cell and tells it to draw at the next position. Etc.
To do what you want, you could configure the scroll view to not copy on scroll. Then, the table view will be asked to draw everything whenever it is scrolled. Then, you would implement the tableView(_:willDisplayCell:for:row:)
delegate method and apply the alpha value to the cells at the top and bottom edges of the scroll view.
But that's probably not a great approach.
I think you may have better luck by adding floating subviews to the scroll view that are partially transparent, with a gradient from fully opaque to fully transparent in the background color. So, instead of the cells fading out and letting the background show through, you put another view on top which only lets part of the cells show through.