Calculations of the visible rect can be a heavy operation as it depends of the superviews
visible rect. They have to be transformed and intersected together to create the result.
This calculation is a recursive operation that travels up the view hierarchy all the way
to the top.
Updating the tracking areas is also a recursive operation. But it travels down the view hierarchy
instead. It will calculate the new tracking area using the visible rect for the current view. For
each view it updates it will get the visible rect that has to travel all the way up the view
hierarchy to calculate it by transform and intersect them together. This results in that the visible
rect will be calculated for each view multible times. This makes it a very slow operation, specially
for deeper view hierarchies.
This fix will send along the visible rect for the superview when traveling down the
view hierarchy. This means that the visible rect does not need to travel up the view hierarchy
to be calculated. It will just need transform and intersect the provided rect for its superview
with the one from itself.
This makes updating views much faster when they need layout. This will make resizing browser window and changing split views sizes much smoother.
The effectiveAppearance is inherited from the superview. The superviews appearance is passed along as it is recomputed down the view hierarchy.
Also the current appearance is saved on each view to make it possible to only change the theme states when the appearance is changed.
This speed improvement is very notable when resizing a browser window of altering the size of split views.
The fix uses a variable on the window to control when to update the tracking areas.
If the view is not connected to a window the tracking areas will not be updated as they will
be when added to a window.
Also fixed CPView -(BOOL)inLiveResize
If a view is added during a live resize, it will not receive a
willStart notif.
If a view is removed during a live resize it will not receive a Didend
notif.
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
Didier KorthoudtandGitHub
Martin CarlbergandGitHub
Didier Korthoudtandcacaodev
daniel
Didier Korthoudt
daboe01
Alexandre WilhelmandGitHub
Aparajita Fishman