This PR adds the support of scaling in CPView.
There are two new public methods in CPView : -(void)scaleUnitSquareToSize: and -(void)setScaleSize:
-(void)scaleUnitSquareToSize: works exactly as in COCOA, it means if you set a first scale to 0.5 and then 0.5 again, the scaleSize of the view will be 0.25
-(void)setScaleSize: works with the value given. If you set 0.5 after you just seted 0.5 the scaleSize will be 0.5. This method is definitly better in using, specially when using the scaleSize binding with a slider.
Test app in Tests/Manual/ScalingTest
This change begins to clean up the control flow of copy and paste. Before, copy and paste was dealt with partly in CPPlatformWindow, partly in CPApp and partly in CPTextField.
Now, CPApplication has been removed from the path, simplifying it down to the two more expected actors.
This fix switches to full native copy and paste in browsers which support it. This allows copy from anywhere - a collection view, a table view and so on - without the browser greying out the copy menu or beeping.
In the future this can easily be extended to copy and paste images as well.
This change also improves Safari paste support. In recent versions of Safari, pasting from the system clipboard into Cappuccino has been impossible. This remains impossible due to the lack of beforepaste events, but now the code cleanly switches to a Cappuccino-only paste at least.
Without this feature, attempts to paste data into a Cappuccino app (outside of a text field) are handled by redirecting the paste into a hidden text field. Then a paste event is generated from whatever is captured in this field after a 0 timeout. This method is prone to timing related bugs where the paste event actually has an empty clipboard.
With this new feature we read the paste data directly from the browser's native paste event when the browser supports it (Chrome 10+, Safari 5+, Firefox 22+). This is much more dependable and may in the future also enable us to read other types of paste data such as images.
This has the added benefit of ignoring unknown/unsupported prefixes, providing the property itself is camel-cased.
For example:
"LinearBackground" -> "linear-background"
"Linear-Background" -> "linear-background"
"linear-background" -> "linear-background"
"fooLinearBackground" -> "linear-background"
and
"WebkitLinearBackground" -> "-webkit-linear-background"
"MozLinearBackground" -> "-moz-linear-background"
etc..
For example, the following CSS property names all resolve to the same correct JS equivalent for the current browser:
* CPBrowserStyleProperty('TransformOrigin') -> 'WebkitTransformOrigin'
* CPBrowserStyleProperty('transform-origin') -> 'WebkitTransformOrigin'
Before this fix, popoverDidShow: would not be sent to popover delegates when the app ran in Firefox due to Firefox now recognising the -webkit-transition property, but not the webkitTransitionEnd event.
Also, before this fix popover animation was only implemented for Webkit based browsers.
This fix resolves that issue and in addition adds full support for animated popovers in all browsers that support CSS transitions. The fix also improves Cappuccino's general support for CSS3 animations.
Apparently Rhino doesn't have `<input element>.setAttribute` and an error would be thrown in `CPCompatibility.j`: `Cannot find function setAttribute in object [object Object].`
We were compensating for a bug in Safari, older versions of Chrome and Firefox in our input placement. But new Chrome and neither IE 8 nor IE 9 needed it which resulted in the text being off in those browsers.
The problem in particular is that we can't change from AppKit to Native scrollbars or vice versa once an iframe has been loaded. Until we find a way to do so, this less flexible solution will have to do. Note that if the loaded URL passes the SOP, but the content contains links to URLs which do not pass the SOP which can be brought up in the web view, CPWebViewScrollAuto will not work correctly and CPWebViewScrollNative should be used instead.