Previously, during frame updates, we were writing the css values we
just read before.
Canvas sizing is preserved as it is needed when the view has custom
drawing.
Fixed: When only animating frameSize, there’s no matrix defined. This is now
correctly handled.
New: The animator can explicitly request frames updates when the frameOrigin
keyPath changes with the new method [animator setWantsPeriodicFramesUpdates:YES]
When a view belonging to a CPViewController is hidden, unhidden, added
or removed, its viewController receives the appropriate message.
Added AppKit/CPViewControllerTest.
Previously, when double-clicking on a table cell to edit it, there was a possibility of a race condition. A refresh of the display was requested, then the run loop was passed through once. But it was possible for the display refresh to not be queued when the run loop was passed through, in which case the refresh would cancel the editing. Or at least I think that's what was happening. ;-)
This commit (hopefully) eliminates the race condition by synchronously refreshing the layout and display.
Made some miscellaneous formatting fixes as well.
For some (yet unknown) reason, when declaring a view with tracking area
in a CIB, there’s some weird things happening that try to use the
_trackingAreas array when it’s not yet initialized… So, replacing
_trackingAreas.length by [_trackingAreas count] resolves the problem.
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)
Previously, when using a viewBased CPTableView Cappuccino just crashed.
This was due to the new appearance feature. Indeed, at the end of the method initWithCoder: of CPView, we set the appearance of the current view and the themeStates of the view and its subviews. For an unknown reason some of these subviews were not completely initialized (see comment line 3742), this made crashed cappuccino because _themeState was null.
To fix this issue, we send the method setAppearance when the current stack was performed. (Magic setTimeout...).
This is for sure not the ultimate best fix, but it's prevent to have a broken master. We will need in the future to fix this issue in a better way.
The purpose of this feature is to create theme for every object of the AppKit. Previously, we could not theme object like CPColor, however CPColor could be very interesting to theme, value like alternateSelectedControlColor were hard coded in the framework. With this PR, we can now theme a CPColor and take some values from the current theme of the application. Then, this PR offers the possibility to refactor the themeDescriptors, some classes contains theme attributes for other class (CPTabView and CPTabViewItem for instance).
How doe it work ? A new category _CPObject+Theme.j has been added to the AppKit. This category contains every theme methods needed to theme an object (previously this category was in CPView). We add utils method like _encodeThemeObjectsWithCoder: and _decodeThemeObjectsWithCoder: in this category to be able to code and decode easily a coder for every object (this is generic).
This PR did not refactor the themeDescriptors, it only add this new mechanism for the methods alternateSelectedControlColor and secondarySelectedControlColor of CPColor. We will need to refactor that gradually
Previously, when making a right click and when a cappuccino menu was not displayed, the system menu was displayed. Now we don't display this menu anymore as in cocoa. We only display when making a right click on a CPTextField.
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
This patch adds the `CPAppearance` class and uses it where needed.
There is nearly no impact, but in `_CPPopoverWindowView` where the
`CPPopoverAppearance` needs to be converted to a `CPAppearance` object
nib2cib support has also been added.
*This patch brings no new functionality.*
cacaodev
Didier Korthoudtandcacaodev
Martin CarlbergandGitHub
Didier Korthoudt
daboe01
Alexandre WilhelmandGitHub
Aparajita Fishman
Antoine Mercadal