This prevents a buildup of large arrays with a lot of values and then choose one row and throw away the rest. This is great for speed and a must for lazy loading.
Previous there was a optimization for this but it was only effective for short combined key path like 'a.b'. This pull request makes it effective for any kind of length of a combined key path like 'a.b.c.d...'.
This is done by returning the object at a row in the first found CPArray in the key path
that is divided in a first and second part.
The first part is never a combined key path. The second part can be a combined key path.
If this optimization is not done we will create an array with the valueForKeyPath value on each row and then pick
the wanted value for the row and throw away all the other rows. It is much more effective to first
pick the row and then do the valueForKeyPath on the rest of the key path.
Previously, every AppKit tests used the same sharedApplication. Due to this implementation, a could not pass because a previous test made failed the current test. For instance, a test could fail because the window of the previous test resigned (just imagine a new window is the key window in the current test), and this resign could raise an error. The error was displayed for the current test thought this test was perfect !
We now instead of using sharedApplication create a new CPApplication per unit-test file in the class method setUp.
Before this fix, the CPTableColumn binder was not correctly reloading
the table when the number of rows changed. Now we reload fully the
dataviews when the number of rows changes. If no rows are
inserted/deleted, there is an optimization: we just need to reload the
objectValues and leave the dataviews untouched.
With Test in Tests/AppKitCPTableViewTest.j
Fixes#2317
This PR adds the method viewAtColumn:row:makeIfNecessary: in CPTableView.
This method first attempts to return an available view, which is generally in the visible area. If there is no available view, and makeIfNecessary is YES, a prepared temporary view is returned. If makeIfNecessary is NO, and the view is not available, nil will be returned.
An exception will be thrown if row is an invalid row index and if column is an invalid column index.
The returned result should generally not be held onto for longer than the current run loop cycle. Instead they should re-query the table view for the row view.
UnitTests in Tests/AppKit/CPTableViewTests.j
Note: It seems that CPThemeStateKeyWindow cannot be tested in the
console. A manual test with multiple windows and table views exists in
Manual/TableTest/OldTest/
Possible regression from #fe260a8
Regression: -reloadData does not reload views any more even if the table is empty (see CPOutlineViewCibTest).
BUG: -removeTableColumn: error.
Conflicts:
AppKit/CPOutlineView.j
AppKit/CPTableHeaderView.j
AppKit/CPTableView.j
Before the table view would send a CPTableViewSelectionDidChangeNotification whenever the number of rows in the table decreased, regardless of if any selected rows actually became deselected. This could be a needless performance drain in the common case where other program components update and reload on selection changes in a table or outline view.
Martin Carlberg
Alexandre Wilhelm
Antoine Mercadal
cacaodev
Alexander Ljungberg
Johan Stille
Alexander Ljungberg
Blair Duncan
Francisco Ryan Tolmasky I
aburkhalter