CPTreeNode.j:
* Correct index calculations in insertObject:inChildNodesAtIndex: and replaceObjectInChildNodesAtIndex:withObject:. Nodes no longer misplace during same-parent or cross-parent moves.
* Update _removeChildNode: to call removeObjectFromChildNodesAtIndex:. This ensures detaches notify childNodes observers on the original parent.
CPTreeNodeTest.j:
* Add test coverage for same-parent replacement, cycle rejection on replace-path, KVO during cross-parent moves, mutableChildNodes proxy operations, insertion bounds, non-recursive sorting, isLeaf, and descendantNodeAtIndexPath: edge cases.
* Disable same-parent childNodes KVO test. CPKeyValueObserving.j coalesces nested change notifications on the same key, which drops the inner removal event.
* Disable parentNode KVO test. No setParentNode: method exists to instrument.
* Add inline comments to both disabled tests explaining these mechanisms.
CPTreeNode: same-parent child moves no longer misplace the moved node — this corrects a defect in the class itself, properly exposed by the test.
Separately, the unit test's expectation for a root node's index path was itself wrong.
Corrected to match the class's existing, contract-correct behavior.
Test unit now runs cleanly.
This is needed when a plain NSView is use without a Custom class name as it will otherwise try to create a NSView.
Also the Class Swapper is only used when the 'Instantiation' is check for 'Prefer code' under
the 'Runtime Behavior' header in the Document tab in Xcode. If this is not checked the '_CPCibCustomView'
is used instead of the Class Swapper.
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.
David Richardson
daboe01andGitHub
Martin Carlberg
Didier KorthoudtandGitHub
jasperdebandMartin Carlberg
cacaodevandMartin Carlberg