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.
Before this commit, a tab view could have an empty selection with the
following circumstances:
- The tab view was not created in IB
- the Tab View selection had not binding management
With test.
When a view belonging to a CPViewController is hidden, unhidden, added
or removed, its viewController receives the appropriate message.
Added AppKit/CPViewControllerTest.
Previously, when a view was about to layout, only layoutSubviews was called. Now the methods viewWillLayout and viewDidLayout are called as well. This is like in Cocoa.
This PR fixed the issue with the appearance and the view based tableView. We now handle everything related with appearance when making the layout of a view.
This PR removed a small optimization in CPView. Now when making setNeedsLayout and setNeedsDisplay, the methods drawRect: and layoutSubviews are always called even if there are not override. (As in cocoa)
Each default (and only supported) CPAppearance now have an associated
theme state. As the appearance is correctly propagated in CPViews
hierarchy, it is now possible to have dark controls when the an
ancestor view has a dark appearance.
Added automated tests
Martin Carlberg
daboe01
Didier KorthoudtandGitHub
jasperdebandMartin Carlberg
cacaodevandMartin Carlberg
Didier KorthoudtandMartin Carlberg
Alexandre Wilhelm
Didier Korthoudt
Aparajita Fishman
Antoine Mercadal