GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
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.
It is totally possible that the user will want to update a single cell. In that case it is a huge waste to reload everything. I actually have an implementation of this somewhere, it isn't that hard.
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
i am closing this because the current implementation only reloads visible cells. There will be not measurable speed gain from constraining any further.
Milestone: 1.0. Labels: #wont-fix, AppKit, feature. What's next? A reviewer or core team member has decided against acting upon this issue.