Previously, nib2cib would not correctly calculate the app/resource directories if the xib was in a subdirectory of Resources. Also, image resources in subdirectories did not have the subdirectory encoded with the image name.
Now xibs and images may be anywhere under Resources.
Fixes#1960.
Previously, _createDOMImageElement was not called until after [super initWithCoder] was called. But that call would end up in CPImageView -setObjectValue, which would attempt to access _DOMImageElement before it had been created.
Now _DOMImageElement is checked before being accessed or created.
Previously, a case could arise where a text field was set as the initial first responder but during cib loading was not yet assigned to a window. In this case _isWithinUsablePlatformRect would fail.
Now _isWithinUsablePlatformRect checks to make sure the text field has a window.
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.
Without this fix, the `appkit_tag_dom_elements` flag would only affect CPImageViews unarchived from a coder (e.g. in a collection view, from a cib). It would have no effect on a CPImageView created in code.
This change refactors the _DOMImageElement code to a shared method, reducing redundancy while fixing the bug.
Without this fix, code like `[[[CPImage alloc] initWithContentsOfFile:nil] description]` would cause a crash.
This fix makes `[[CPImage alloc] initWithContentsOfFile:nil]` behave like its equivalent in Cocoa: it returns nil without warning or error.
If a cib file had a custom CPWindow subclass, that cib file would not be properly processed by flatten as it'd fail to find the relevant class (the fact that the class can't be found is an issue in itself). This would cause an exception.
This fix makes CPCibWindowTemplate act similar to CPCibCustomView when the referenced class can't be found: it instantiates a regular CPWindow. This is sufficient for flatten's purposes.
The fontinfo and imagesize Xcode projects still explicitly refer to using the Mac OS X 10.5 SDK, while all other Xcode projects simply refer to the latest Mac OS X SDK, with no explicit OS version. This change modifies these two projects to mirror other Xcode projects in the project.
Fixes#1957
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.
This change brings nearly all copy and paste related into a single, self-contained class. This new class is still somewhat coupled to CPPlatformWindow+DOM.j in the sense that it's highly specific and meant to be called in a very specialised way. Despite this, it's still a significant decoupling and the new code is more readable and easier to follow.
Without this fix, if a menu item was disabled it could only be automatically re-enabled if the menu item had a `validateMenuItem:` or `validateUserInterfaceItem:` enabled target.
This meant that for example if the Edit > Select All menu item was validated when the first responder was something like a collection view, it'd become disabled. If then the first responder was changed to a text field and revalidation occurred, the menu item would not become enabled and Select All would not be possible in the text field neither through the Edit menu nor the Cmd-A/Ctrl-A keyboard equivalent.
This fix ensures that menu item validation does not only take negative action (disabling enabled items which should be disabled), but also positive action (enabling disabled items which should be enabled), even when there's no `validateMenuItem:` or `validateUserInterfaceItem:`.
Image copy and paste to and from the system clipboard is not available in Cappuccino today. However, the image in the collection view can be used to test internal Cappuccino copy and paste (using Edit > Copy, Edit > Paste from the Cappuccino menu).
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.
These targets might be rare but could occur in some Cappuccino text editor widget, in which case our standard native paste handling from Safari should work fine.
Without this fix, when text was copied from a CPTextField, the value would be copied into the system clipboard (if possible), but not into the Cappuccino pasteboard. This meant that the text could not be pasted back in Cappuccino using e.g. Edit > Paste from the Cappuccino menu.
This fix ensures the appropriate text is copied both into Cappuccino's pasteboard and the system clipboard (when possible).
This test makes it easy to test copy and paste both inside a Cappuccino app, and externally to and from other Cappuccino instances in other browser, or other applications, when using a text field or a collection view as the source/destination.
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 fix, certain JS contents could cause `- CPDictionary description` and `- CPArray description` to crash.
This change limits how deeply the description code will recurse before returning a default "…" description.
Without this fix, code like `[@{ "a": window } description]` would crash with a "Maximum call stack size exceeded" exception.
Now`CPDescriptionOfObject()` function simply describes the window object as `window` rather than trying to serialise it into a huge description string.
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 change adds nib2cib support for `NSValue` when the value represents a NSPoint, NSSize, NSRect or an NSRange, which enables user defined runtime attributes of these types to be set in Xcode and then properly decoded in a Cappuccino app.
Without this fix, CGRectFromString would call CGSizeFromString with a value like "{1, 2}}" (not the extra trailing "}"). Although CGSizeFromString didn't complain, it wasn't correct either.
Firefox is not accepting the initial values for these two attributes, making it crash with an ILLEGAL VALUE error in any application using CPBezierPath (especially ones with CPPredicateEditor that is using bezier path to draw the selection arrows.)
Without this fix, trying to build Cappuccino or run a jake script with a too low `ulimit -n` would cause a fatal error.
This change will automatically increase the ulimit when possible and only error out when it's not. The automatic change does not permanently affect the terminal session as it only targets the soft limit.
Previously it was possible to select rows in a CPTableView even if there wasn't columns. It was also possible to make a drag/drop.
This PR fixes theses both problems.
Alexander Ljungberg
Aparajita Fishman
Martin Carlberg
Antoine Mercadal
Glenn L. Austin
Blair Duncan
Alexandre Wilhelm