My common Renderer[-A] trait has the following method signature:

def componentFor(owner: Owner, value: A, cellInfo: companion.CellInfo)

Where Owner is say, a ListView[], Tree[] or Table, and CellInfo contains the extra component-specific stuff like row, isSelected, isFocused and so on. (Assuming ListView and Table are retrofitted with CellView/RenderableCellsCompanion and so forth)

The advantages of this abstraction are compelling; for instance, this mixin will provide an identical renderer for Tree, ListView and Table:

trait RenderFiles {
  this: RenderableCells[File] =>
  import companion._
  renderer = Renderer(_.getName)
}

Also, the LabelRenderer implementation in Table can be entirely pushed up to the CellRendererCompanion level of abstraction.

However this causes backwards compatibility issues with the existing componentFor methods in Table and ListView. I have made some attempt at accomodating user code that overrides either, but it may still break existing code. I'm not sure how to handle this case.