Prevously, when removing a CPTableView or a CPScrollView, the CPNotificationCenter kept a reference of these observers in the notification center.
Now, the CPNotificationCenter does only have a observer when necessary.
Without this change, using a traditional scroll wheel mouse with discrete steps would result in very slow scrolling in Firefox.
With this fix we handle these events like in Cocoa: as "[im]preciseScrollingDeltas", which `CPScrollView` in turn knows to apply the configurable line scroll amount for. For backwards compatibility, [event deltaX] and [event deltaY] are premultiplied with a suitable constant, while [event scrollingDeltaX] and [event scrollingDeltaY] show the true values needed.
Browsers other than Firefox seem to always send pixel scrolling information even for old style scrolling devices, at least on the Mac, so are not affected by this change.
Fixes#2013.
Previously the inner element's offsetWidth was tested before and after setting the overflow to scroll. This is unnecessary, we can just set the overflow to scroll and test the outer element's clientWidth vs. offsetWidth. By definition, clientWidth does not include scrollbars, whereas offsetWidth does. So if they are equal then overlay scrollers must be in use.
Note that FireFox (as of version 22) does not support overlay scrollers, so even if the system does, Cappuccino will not on FireFox unless the programmer forces overlay scrollers.
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.
This could either be due to autohiding or they usage of overlay scrollbars. Not showing it matches Cocoa and makes sense because it takes up space for no reason without the scrollbar.
The calculation of the number of pixels outside of the clip view assumed fixed, space consuming scrollbars even when overlay scrollbars were used, leading CPScrollView to always think a few more pixels could be revealed.
If there is no vertical scroller, or there is no horizontal scroller, due to autohiding or scroll view settings, a single visible overlay scroller should extend all the way to the edge of its dimension.
The Lion style scrollbars are inconvenient for users without a touch scrolling device, and we do not have a way to detect whether the user has such a device yet.
---
Adds -scrollViewWillScroll: and -scrollviewDidScroll: delegate methods to CPScrollView.
These methods are not in AppKit but exist in UIKit. Useful for lazy loading data in a view, for example a CPTableview.
Tested in the CPScrollView example.
Conflicts:
AppKit/CPScrollView.j
CPScroller: send action when dragging starts instead of immediately on mouse down.
Test: added delegate methods to the top-left scroll view in CPScrollView example and log.
Alexandre Wilhelm
Alexander Ljungberg
daboe01
Aparajita Fishman
Ilya Kulakov
Aparajita Fishman
Alexander Ljungberg
Jacek Galowicz
Randall Luecke
Antoine Mercadal
Aparajita Fishman
Brian Donovan
cacaodev