- make every object calling getBinding:forObject: aware of this change
- implement _CPCheckBoxValueBinder to handle binding to the value of a checkbox Closes: #1083
- re-implement CPTextField's behavior for controller markers using the new binder class
- disabled some tests that are not compliant with Cocoa
This fixes the error where if a row was selected below a certain item and that item was collapsed, the row selection would remain fixed in place even while the item it was highlighting moved upwards.
- should not force empty space above and below, but only where the tabs are
- box should fill frame when no tabs are present
- ivars should be prefixed with underscore
- not sure about the current background color code, may revisit
CPArray insertObject:inArraySortedByDescriptors: now quickly inserts objects at the end of the array if no sort descriptors are specified.
CPArrayController initialises its sort descriptors to an empty array.
Fixed: array controller's addObject added objects to the arranged objects array in a different order than in the content array if no sort descriptor was set.
- setValue:forKeyPath will now get call setValue:forKeyPath again on the value of the first part of the key path
- override valueForKeyPath: and valueForKey: in CPObjectController's CPControllerSelectionProxy to return controller markers when appropriate
- override setValue:forKeyPath: and setValue:forKey: in CPObjectController's CPControllerSelectionProxy to bypass possible controller markers
This commit also removes previous hacks for compound paths and adds test cases for the errors. All this is related to issue #967.
Before the table view would send a CPTableViewSelectionDidChangeNotification whenever the number of rows in the table decreased, regardless of if any selected rows actually became deselected. This could be a needless performance drain in the common case where other program components update and reload on selection changes in a table or outline view.
This would break key-value binding setups where a CPCollectionView's content property was hooked up to a CPArrayController's content or arrangedObjects property since the CPArrayController maintains the same object and calls setValue:forKey: with the same object the CPCollectionView already has. Therefore we cannot skip calling reloadContent even when the incoming content array is the same one we got before, because most likely the contents have changed out from under us.
CPArrayController was erroneously using canRemove to determine whether explicit removal could take place, when in fact the documentation for [NSObjectController canRemove] (NSArrayController does not override canRemove) states that it returns "YES if an object can be removed from the receiver using remove:, otherwise NO", implying that it should only be used to check whether there is a selected element that can be removed (for example, to bind the enabled state of a toolbar button to a CPArrayController's canRemove property). It should not be used to decide whether a specific object can be removed or not.
Klaas Pieter Annema
Alexander Ljungberg
Johannes FahrenkrugandFrancisco Ryan Tolmasky I
Ross Boucher
Brian Donovan
cacaodev
Andreas Falk
Antoine Mercadal