Cocoa specifies that viewDidHide will be called when an unhidden view is added to a view hierarchy with a hidden ancestor view, and viewDidUnhide is called when an unhidden view is removed from a view hierarchy with a hidden ancestor view. This was not the case in Cappuccino.
This commit adds that functionality, and also removes a spurious viewDidHide/viewDidUnhide call that was generated as a side effect in initWithCoder.
Tagging with UIDs can make it much easier to debug encoding/decoding related bugs where it's not clear that the right view ended up in the right spot.
The new data attribute is called "data-cappuccino-uid".
Also collect and simplify appkit_tag_dom_elements code a little.
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.
Functions are used everywhere to set width or height in the DOM except in the method lockFocus. This will cause IE8/9 to report error if the width or height is negative in this method.
Previously, tooltip system was using bubbling event. This was actually making impossible to see a view's tooltip if the parent view also has a tooltip. This patch changes the capturing mode from bubbling to capture.
Previously, no check was done to ensure a next/previous key view belonged to the same window as the view to which it was being chained. This could lead to an infinite loop.
This commit will only set the next/previous key view if the proposed's views window is either nil or is the same as the receiver's window.
Closes pull request #1851
Previously, Cappuccino was using preprocessor macros internally for the CGPoint/Size/Rect/Inset/Affine functions, as well as for CPRange. These macros had the same name as the corresponding function, but began with _. The functions were actually defined using the macros.
The motivation behind using macros was to increase performance by reducing function calls. However, there were a number of problems with this approach:
- There was an artificial dichotomy between _CG macros and the corresponding CG functions. We never completely replaced CG function calls with _CG macros. In fact, they were often mixed up in the same file. There was an extra burden on the programmer to remember to use the macro instead of the function.
- If a method call was passed as an argument to a macro, performance could actually be significantly *worse* than a function call. For example, _CGGetRectMakeCopy([view frame]) would expand to `{ origin:{ x:[view frame].origin.x, y:[view frame].origin.y }, size:{ width:[view frame].size.width, height:[view frame].size.height } }`. So instead of a single objj_msgSend and a single simple function call, we ended up with 4 objj_msgSend calls, which are way more expensive than simple function calls.
- Because of this expansion problem, to use macros efficiently required us to remember to use variables for all macro parameters. This didn't happen, and shouldn't have to happen.
- Finally, with modern Javascript engines, function call overhead is so small that it really isn't worth using the macros.
This commit eliminates the _CGGeometry, CGAffineTransformation and CPRange macros and replaces them with function calls.
BREAKING CHANGE:
The macros are no longer available. They could only be used with compiled code, but if there is any user code that used them, they will have to be replaced with the corresponding functions.
Previously, calling setPostsFrameChangedNotifications:YES or setPostsBoundsChangedNotifications:YES would immediately result in the notification being sent. Cocoa will only send in this context if:
- setPosts[Frame/Bounds]ChangedNotifications:NO was called.
- The frame/bounds changed between that call and the call to setPosts[Frame/Bounds]ChangedNotifications:YES.
We are currently not tracking pending changes, so this commit removes the sending of the notification completely in those methods.
Fixes#1076
Previously, Cappuccino would resize in such a way that a view's size ratio to its superview would not be maintained.
This commit ensures that size ratios are maintained during resizing.
Patch contributed by @davidkhess
Fixes#357
Without this fix, CPView's resizeWithOldSuperviewSize: would simply resize subviews at the rate of 1 pixel for every 2 pixel change.
This change introduces a new method of resizing views to a ratio of the size of the superview.
Patch contributed by @davidkhess
In Cocoa, viewWillMoveToSuperview: and viewDidMoveToSuperview: are called when views are instantiated from code or from a nib.
Previously in Cappuccino, when a view was instantiated from a cib, the _subviews of the view were directly set from the decoded subview array. This short-circuited all of the normal notifications a view receives when added to a superview, including viewWillMoveToSuperview: and viewDidMoveToSuperview:. As a result, some views that override these methods, such as CPSearchField, were not set up correctly when instantiated from a cib.
With this commit, subviews instantiated from a cib are manually added to their superview, thus ensuring they go through the same cycle as views instantiated from code, and ensuring that viewWillMoveToSuperview: and viewDidMoveToSuperview: are called.
Closes#1699
If a view to be added is already a subview, but doesn't yet "know it" due to being only partially decoded, a corrupted view hierarchy with duplicate views would be set up, which is very hard to debug.
In the modified test described in #829 performance improves by at least 30% and that's with a significant addSubview: component diluting the test.
This change should improve outline and table view performance.
- CPView and subclasses support multiple-value hidden bindings.
- CPControl and subclasses support multiple-value enabled bindings.
- CPWindow and CPBox support multiple-value title with pattern bindings.
- CPButton supports multiple argument + target bindings.
- CPImageView and CPTextField support multiple-value editable bindings.
- CPMenuItem supports multiple-value enabled bindings.
- Fixed bugs in CPObjectController with simple collection operators.
- CPColorWell uses black as the placeholder color.
- Runtime object attributes from a cib are applied as they are read, not deferred.
- NSNumberFormatter now reads the number style from the xib.
- Normalized some parameter names.
- Formatting.
- Test app for all binding types.
- Popovers are implemented as child windows.
- Renamed _CPAttachedWindow/_CPAttachedWindowView to _CPPopoverWindow/_CPPopoverWindowView, since that is its only use.
- The default for CPView -acceptsFirstMouse is now NO, per Cocoa. Subclasses override this as necessary.
- _CPWindowView -hitTest returns self it the mouse is within a resize region, which may be outside the window's frame.
- Fixed an off by one bug in CPDomWindowLayer -insertWindow:atIndex:, where inserting a visible window behind a window it is already behind would cause it to move up one from its intended position.
- Updated the ChildWindows and CPPopover test apps.
- Removed unnecessary code at beginning of CPTextField -becomeFirstResponder that might have been a hack to get around a bug I fixed.
- Fixed race condition in setTimeout closure in CPTextField -becomeFirstResponder.
- CPWindow -setInitialFirstResponder now works reliably and follows Cocoa behavior in that if -makeFirstResponder is called with something other than the window before the window is first shown, it will override the initial first responder.
- Like Cocoa, until the first responder is set during window load, the first responder is the window by default, not the content view.
- Optimized search for any view that has a previous/next key view set.
- Sheets can become key windows again.
- CPWindow -recalculateKeyViewLoop now just marks the loop as dirty, per Cocoa docs.
- CPWindow -autorecalculatesKeyViewLoop now behaves per Cocoa, it only has an effect when views are added or removed.
- If the first responder does not have a valid previous/next key view, it does not resign to nil, per Cocoa behavior.
- Code optimization and cleanup.
- Test app (KeyViewLoopTest) that demonstrates various scenarios.
Both controls and cells can have tags in IB, but Cappuccino has no cells. If the control has a tag, that takes precedence. Tag reading was moved to NSControl from NSView, since NSView does not have a tag in Cocoa.
Without this optimisation nil or 0x0 sized image slices in three part and nine part images result in useless empty divs.
Eliminating these divs should improve performance and reduce memory usage.
Although exact memory usage is hard to measure, in a large app the number of divs on screen went from 1012 to 984, a reduction of about 2.7%.
Aparajita Fishman
Alexander Ljungberg
Martin Carlberg
Antoine Mercadal
Blair DuncanandAparajita Fishman
Andrew HankinsonandAparajita Fishman
cacaodev
aparajita
Aparajita Fishman