Previously, we could only give a selector and a target for perform in the runLoop. Now we can give a block.
This feature is used in the CPTextField class. Previously, when we wanted to call a function at the end of the stack we used window.setTimeout, however due to HTML5 specifications this wasn't called just at the end of the stack but at least 4ms (more information here https://developer.mozilla.org/en-US/docs/Web/API/WindowTimers/setTimeout#Minimum_delay_and_timeout_nesting). Now we give a block to perform, and this block will be performed in the next runloop.
Unittest has been added in Tests/Foundation/CPRunLoopTest.j
This PR adds the feature of CPNotificationQueue.
Cappuccino provides a framework for sending messages between objects within
a process called notifications. CPNotificationQueue objects (or simply notification queues)
act as buffers for notification centers (instances of CPNotificationCenter).
Whereas a notification center distributes notifications when posted,
notifications placed into the queue can be delayed until the end of the current pass through the run loop
or until the run loop is idle. Duplicate notifications can also be coalesced so that only one notification
is sent although multiple notifications are posted. A notification queue maintains notifications
(instances of C¨Notification) generally in a first in first out (FIFO) order.
When a notification rises to the front of the queue, the queue posts it to the notification center,
which in turn dispatches the notification to all objects registered as observers.
More informations here :https://developer.apple.com/library/prerelease/ios/documentation/Cocoa/Reference/Foundation/Classes/NSNotificationQueue_Class/index.html#//apple_ref/occ/instm/NSNotificationQueue/enqueueNotification:postingStyle:coalesceMask:forModes:
Unit-Tests in Tests/Foundation/CPNotificationQueueTest.j
For example the method ’initWithName:’ will return different abbreviation depending on the order CPDictionary returns keys from the method ’keyEnumerator’. As this is undefined the answer can vary. Test cases now handle all cases.
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)
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 contains a very naive implementation of the
NSVisualEffectView. This will only work on very recent unreleased
version of Safari, but should be supported by all at some point. This
allow to use the Yosemite/iOS blurry effect.
Not all options are supported (especially the
`CPVisualEffectBlendingModeBehindWindow` mode…). But hey! it’s a start
:)
Tests in Manual/CPVisualEffectViewTest
When parsing a predicate format that contains a constant boolean expression
(e.g., 'key = YES') the value of the returned constant value expression has
the wrong type. Instead of using native types as values, the parser uses
[CPNumber +numberWithBool:].
This commit changes the format parser (CPPredicateScanner) to use native
booleans for constant value expression.
There's a test case that checks the parse result and an additional test
that ensures boolean expressions evaluate as expected with different kinds
of objects. The latter test passed before the fix but was added to ensure
compliance with Cocoa.
Previously, every AppKit tests used the same sharedApplication. Due to this implementation, a could not pass because a previous test made failed the current test. For instance, a test could fail because the window of the previous test resigned (just imagine a new window is the key window in the current test), and this resign could raise an error. The error was displayed for the current test thought this test was perfect !
We now instead of using sharedApplication create a new CPApplication per unit-test file in the class method setUp.
Previously, the unittests for the CPDatePicker broke the tests suite of cappuccino. A CPDatePicker uses a CALayer, and the CALayer display methods wasn't wrap in a #if PLATFOrM(DOM). Now it does, so during the tests we do not try to access do the element document anymore.
This PR fixes also some warnings when compiling.
This PR adds the delegate methods applicationShouldTerminate and applicationShouldTerminateMessage in CPApplicationDelegateProtocol.
The delegate applicationShouldTerminate does not exactly work as in Cocoa. In Cocoa, this method is called in CPApp -terminate, but in cappuccino it is called in the method onbeforeunload of the window. In JS, this is the only time where we can prevent to reload the HTML page. If the developer cancel to reload the page, the browser will ask the user if he wants to reload or not the page thought (natural behavior of js).
The method applicationShouldTerminateMessage allows you to define what will be the text displayed in the confirmation alert.
Test app in Tests/Manual/CPPlatformWindow/
This PR adds the features CPUserNotification and CPUserNotificationCenter in Foundation.
The CPUserNotificationCenter allows you to send user notification to the system.
Right now, we only propose what the W3C proposes. We can set for a notification the title, informativeText and the icon.
We only support local notification yet.
The protocol CPUserNotificationCenterDelegate has been added as well.
Test app in Tests/Manual/CPUserNotificationTest
Antoine Mercadal
Martin Carlberg
Martin Carlberg
Alexandre Wilhelm
cacaodev
Malte Tancred