`CPTableView`'s `selectionIndexes` binding shouldn't be set automatically unless the content binding was also set automatically (through a table column binding).
Assume that manual content binding implies a desire to manually bind selection indexes (and sort descriptors) as well.
With this option an array controller driven table view can be sorted by clicking the table column headers without manually setting up sort descriptor prototypes.
If `CPCreatesSortDescriptorBindingOption` is enabled on a table column value binding, sort descriptors will be created automatically. The default value for this option is YES.
- Attributes set in IB are now obeyed.
- Added accessor methods to programmatically style _CPTableColumnHeaderView.
Since we don't have an NSCell and _CPImageAndTextView is supposed to be private, it's better to have the styling methods in _CPTableColumnHeaderView.
Both controls and cells can have tags in IB, but Cappuccino has no cells. If the control has a tag, that takes precedence. Tag reading was moved to NSControl from NSView, since NSView does not have a tag in Cocoa.
will not scroll without the NSScrollView knowing about it
Issue #1675 and maybe a little of issue #1301
This fix will not work without pull
request #1678 - Fixed scrollRectToVisible in CPView
Without this optimisation nil or 0x0 sized image slices in three part and nine part images result in useless empty divs.
Eliminating these divs should improve performance and reduce memory usage.
Although exact memory usage is hard to measure, in a large app the number of divs on screen went from 1012 to 984, a reduction of about 2.7%.
Avoid sending notifications about toolbar items' enabled state needlessly.
Tiling is expensive, but even if the toolbar item ignores redundant `setEnabled:` calls, the cost of notifications alone can really add up when there are many toolbar items.
`CPEvent timestamp` is now in seconds so the double click delay has to be adjusted. Also slightly increased double click interval to account for lower precision.
This would make the popover open with the wrong coordinates if the positioning view was in a window different than the main window, such as a utility window which can't become the main window.
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.
Locking down the line height and vertical alignment explicitly seems to work in Safari 6, Chrome 21, Firefox 14 and IE 8 (although Chrome and IE exhibit some unrelated horizontal jumping.)
This was caused by making text display generally 1 px taller to allow for fractional pixels at the bottom to show. This should however not be allowed to affect positioning (even if there is a fractional pixel below vertically centred text the text should not move up 0.5 px.)
Only the first responder of the key window should receive text input. This is important in multi-window apps or windows with sheets.
In the multi window case it should be possible to switch between two windows with first responder text fields and keep right on typing. First responder status should not be lost, but new typing should always go into the first responder text field of the key window.
For sheets, a text field which was active when the sheet opened should not receive input nor look active while the sheet is open.
If a window contained a text field which was the initial first responder, and the window was displaying a sheet, clicking on the window would cause the text field to alternate between being the first responder and not.
This was caused by the window `orderFront:` setting its first responder to the initial responder if there wasn't any responder yet. This would cause the text field to focus, even that the window wasn't the key window, and then on the next click the text field would blur which would make the text field automatically resign its first responder status.
The solution is to leave the first responder status alone if a window which isn't the key window is `orderFront:`ed. This appears to be more sensible UX in general. You don't expect the first responder of non-key windows to change when you click it's background.