You can clone with
HTTPS or Subversion.
Currently the tableview calls reload data on itself after a drag and when calling reloadColumns:rows:.
After checking the NSTableView I think CPTableView should only recall reloadData on itself when the datasource is set, after that it should always reload the minimum number of columns / rows.
The current reloadData behavior makes it really hard to implement variable sized rows for large tables.
This isn't as much of a problem as I thought. CPTableView will always attempt to reload the minimal number of rows. Unlike NSTableView which will reload all rows when reloadData is called.
The advantage to our approach is that the tableview is always fast even when loading it initially. The advantage to their method is that NSTableView always has all the information it needs available from the start. It would be very hard for us to implement double click to auto-size column because we don't have the required row information available.
I think the larger issue is that reloadDataForRowIndexes:columnIndexes: is not really implemented, it just calls reloadData.
The complexity of implementing is not worth the actual speed gain. In Cocoa's implementation reloadData reloads all the columns and rows. Our implementation only reloads the visual ones. Our implementation of reloadDataForRowIndexes:columnIndexes: would probably also only reload visible columns and rows that are in the index sets. The number of rows visible at one time in a tableview is usually so small that the difference in performance between reloading all or just a subset of visual rows and columns should be negligible.
Milestone: 1.0. Labels: #accepted, #needs-patch, AppKit, feature. What's next? This issue needs a volunteer to write and submit code to address it.
do you have your implementation handy?
could you post it here?
someone may be using it to make a PR.
@daboe01 In the golden future I will be doing a lot of work on CPTableView, including this issue. But I am not in a position to do anything about this now.
seems to be fixed by PR #1892