Previously, when hitting the backspace key on a none editable/enable field, this triggered the browser's back button.
Now it does not anymore.
All credits for @apajarita
Fixed#2189
Previously, when removing a view, Cappuccino didn't clean the notification center. The notification center kept in reference old views.
This PR fix this issue. When a CPView is added to a view, the methods _removeObservers and _addObservers are called. In these both methods we remove and add the observer to the notification center if needed. _removeObservers and _addObservers are called for the view and its subviews. These both methods are called through the method viewWillMoveToSuperview.
When a CPView is removed, we only call the method _removeObservers.
When a CPWindow is closed, we call the method _removeObservers on its contentView.
When a CPWindow is about to be opened, we call the method _removeObservers and _addObservers on its contentView.
Refs #1880
Refs #2024
Test app in Tests/Manual/AttachedSheet2/SheetWindowController.j
Previously, when a CPTextField was in a CPPlatformWindow, the checking of if the CPTextField was usable or not (depending on its position) in a CPPlatformWindow didn't take in account the content-inset of the CPTextField. Now it does.
Previously, the deleteForward:, deleteBackward: and delete: methods in CPTextField called setStringValue, which would consult a formatter, and if the formatter failed all of the text would be deleted.
Now the code has been refactored such that when one of the delete methods is invoked via a key event, the formatter is not used and the DOM event is used, which results in the expected behavior.
A bug in checking the selected range was also fixed in deleteForward:.
The CPFormatter test was updated with buttons to call the delete methods directly to ensure they work correctly when not invoked from a key event.
Closes#1997
This parameter exists on CPView, so it has been removed here. A note was added on the setter to identify that the parameter was defined in the superclass.
Previously, _textFieldBackgroundColor was used as the internal variable, and getter/setter methods were explicitly declared to handle getting/setting this value.
This commit changes the name of the internal variable to match the Cocoa compliant method (backgroundColor/setBackgroundColor). It also declares an @accessor option to auto-generate the getter. The setter is explicitly declared because it needs to mark the object as needing display.
Additionally, the logic for the setting is moved from the older method, setTextFieldBackgroundColor, to the new one, setBackgroundColor, and a comment was made to clarify that the older one was deprecated with a link to this issue.
Previously, the method setTextColor changed the color of the placeholder as well.
Now it doesn't as in cocoa
Test app in Test/Manual/CPTextFieldEditingStyleTest
Previously, the update of the style of an editing textField didn't work.
Now when editing, we can update the font, color, alignment and vertical-alignment of the textField
Test app in Tests/Manual/CPTextFieldEditingStyleTest/
Fixed#2057
If a table view row is selected its text will turn white to offset against the blue selection colour. However, when the table is not the first responder, or the window is in is not the key window, the light grey highlight colour is used instead, but the text remains white.
This fix ensures the text becomes black in this case by utilising the new first responder and key window theme states.
Fixes#2009, fixes#2001.
Previously, selecting an empty text field hid the contentView, causing the placeholder string to dissapear. This fix leaves the contentView of the text field visible when the internal _stringValue is nil or empty.
Fixes#2049
Copy, cut and delete are now disabled if there's no selection in the active text field. Cut, paste and delete are greyed out if the text field is not editable (a label).
Refs #1964.
When the Edit menu is used to cut or to paste, Cappuccino needs to do all the work of making it happen. But the current code relied on the browser doing part of the work.
This fix adds new state so CPTextField can know if it should expect the browser to do some of the work or not.
Refs #1964.
Previously if - CPTextField `deleteBackward:` was invoked without it being a browser backspace key event for an actively edited text field, the first character in the current selection would not be deleted.
This fix makes it so that `deleteBackward:` works properly from any caller. The fix also undoes a mistake in a recent previous commit which prevented the text field from visually updating after deletion.
This matches Cocoa behaviour. Cocoa also supports double click to select the current word but we currently don't know what word is being clicked. In some browsers (e.g. Safari) this will work natively. Chrome on the other hand selects something random after double click on a non editable div.
Like in Cocoa, a non-editable but selectable text can now be clicked and all text can be selected with the Edit > Select All option or the associated keyboard equivalent. Just like in Cocoa this works on selectable text labels as well (text fields without a bezel).
A non-editable text field does not use an input field, and so does not track what is selected within it. We will use a workaround for now but in a CoreText based text field in the future we'd be likely to always have a correct selectedRange and be able to remove this hack.
Fixes#1972.
Without this change, text fields with setEditable:NO but setSelectable:YES could not become the first responder, and so would not listen for copy: events.
This change allows selectable fields to become the first responder, taking advantage of the distinction between first responder and first key responder maintained internally in CPTextField - a merely selectable field does not become the first key responder.
Refs #1972.
Alexandre Wilhelm
Antoine Mercadal
Christophe Serafin
Aparajita Fishman
Andrew Hankinson
daboe01
Alexander Ljungberg
Ashley Williams
Martin Carlberg