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
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.
Only populate the tooltips handler functions when necessary (when there is a tooltip and when the view is in a window) or clear them otherwise.
Tests in /Tests/AppKit/CPViewTest.j
This PR adds the possibility to layout or not a CPView.
Previously, once setNeedsLayout was called on a CPView, it wasn't possible to cancel the layout of the view.
Now we can as in cocoa. The method setNeedsLayout will still work (it calls the method setNeedsLayout: with YES).
UnitTests in Tests/AppKit/CPViewTest.j
Previously, when adding, removing, replacing a CPView, the framework didn't call the methods viewDidMoveToSuperview, viewDidMoveToWindow, viewWillMoveToSuperview and viewWillMoveToWindow as in Cocoa. Now it does.
The main change is that these methods will be called when removing a CPView.
Added unit-test in Tests/AppKit/CPViewTest.j
Every view in the key window now takes on the 'key window' theme state. This makes it easy to theme everything in inactive windows in more muted colours. Also, combined with the first responder theme state of the previous commit we can have visuals like "first responder but in an inactive window" for text views and such things.
When a CPView becomes the first responder it now takes on the 'first responder' theme state, as does all its subviews. This allows it to naturally change appearance when it has the keyboard focus, such as with focus rings and brighter colour schemes.
Without this fix, -CPView convertPoint:fromView was broken due to the changes made in #1998. In particular, the transform for the fromView would be calculated and then just thrown away if the views were in the same window. This happened to work in some specific cases and the lack of unit tests concealed the error.
This fix properly applies the transforms when two views are in the same window without one of them necessarily being inside the other.
Refs #1998.
Previously, certain situations could easily lead to an infinite loop in - CPView nextValidKeyView. For instance, opening a sheet view with no responder returning YES for canBecomeKeyView would freeze Cappuccino.
This was caused by the cycle detection in nextValidKeyView not being able to pick up on cycles where the nextKeyView of the original receiver did not participate. Since content views often have a next key view inside of them, and the views inside rarely have a next key view back "up" to the content view, the content view would never be seen again even if there was a cycle.
This fix detects cycles at any level by remembering all previous visited responders.