The default was to make the first window in the most background layer the key window if nothing else was used.
This does not work well if there is a modal window that should have all the attention.
This solution will first choose the modal window if in modal mode. If not the old variant is used.
There was a problem introduced by pull request #2600 when trying to select and copy text in a selectable text field.
The problem only occurs when the text field is in a modal window.
It was caused by the modal run loop that is present as an eventListener on the CPApplication when in modal mode. It will
force a bail out from the sendEvent: method in CPApplication when trying to handle the event. As the check for key
equivalent is moved down by the #2600 pull request it will never be allowed to handle a copy command from the browser
menu or key equivalent.
The solution is to allow the text field to handle the event if it is selectable. This will also allow the text selection
to be altered from the keyboard with keys like shift-left/right/up/down arrow. Combinations like shift-option arrow also
work for whole word selection.
This was present in a CPTextView.
A press on caps lock should also result in a flagsChanged event.
An event should have the corresponding flag for caps lock in modifierFlags.
This prevents a buildup of large arrays with a lot of values and then choose one row and throw away the rest. This is great for speed and a must for lazy loading.
Previous there was a optimization for this but it was only effective for short combined key path like 'a.b'. This pull request makes it effective for any kind of length of a combined key path like 'a.b.c.d...'.
This is done by returning the object at a row in the first found CPArray in the key path
that is divided in a first and second part.
The first part is never a combined key path. The second part can be a combined key path.
If this optimization is not done we will create an array with the valueForKeyPath value on each row and then pick
the wanted value for the row and throw away all the other rows. It is much more effective to first
pick the row and then do the valueForKeyPath on the rest of the key path.
The msgSend function has always returned nil if the receiver has been nil or undefined.
Example:
var a = undefined;
var b = [a someSelector]; // b = nil
The variable b is now nil.
This pull request adds the ability for the msgSend function to return undefined if the receiver is undefined. If the receiver is nil it still return nil.
The above example again:
var a = undefined;
var b = [a someSelector]; // b = undefined
The variable b is now undefined.
Background.
The use of nil in Objective-C corresponds to the use of null in C and C++ and stands for "no value". A fundamental function in Objective-C is when you send a message to a receiver that is nil the result is again a nil value. This can be very convenient as you don't need the check if a receiver is nil before sending a message to it.
Objective-J adds the ability the use class structures and message send functionality for Javascript in the same way as Objective-C adds this to C and C++. Javascript also has the value null and is handled in the same way for Objective-J. Javascript also has the value undefined that stands for "not yet defined". This can sometimes be confusing and many try to handle null and undefined as the same thing. This is almost what Objective-J and the Cappuccino frameworks always has been doing. They try to always check for both null and ``undefined and always return nil but never undefined. We can say that Objective-J understands undefined but will try to translate it to nil.
Why do we need this change.
Javascript has both null and undefined and Objective-J is a superset of Javascript. It is now very hard to use undefined in Objective-J code as it will always try to translate it to nil. There are some Javascript libraries that use both null and undefined values and they are very hard to use from Objective-J programs today. Same if you decide to use nil and undefined as a value in your own Objective-J code. This small change will make undefined a full member of the Objective-J language. It should be as it is a superset of Javascript. The Cappuccino frameworks will still handle undefined but only return nil.
How will it impact.
Today most methods will never return undefined so this is a very limited problem. If any does this the main concern is if some code will only check for nil and not undefined.
Example:
var a = [someObject someSelector];
If (a === nil) a = 42;
...
If the variable someObject contains undefined the variable a will now be set to undefined instead of nil. But the variable a will then never be set to 42.
The correct way is to check for both nil and undefined like this:
var a = [someObject someSelector];
If (a == nil) a = 42;
...
In CPWindowController, method viewControllerContainerView, implies that it returns something, and it does. It returns the _viewControllerContainerView instance object, and return type should be changed from void to CPView
Method browser:imageValueForItem was defined twice in CPBrowserDelegate. Once on line 43, and the other on line 45. This removes the commit removed the second declaration
Martin CarlbergandGitHub
cacaodevandMartin Carlberg
daboe01andMartin Carlberg
Didier KorthoudtandMartin Carlberg
Didier KorthoudtandMartin Carlberg
Alexandre WilhelmandGitHub
daniel