On 7 Apr 2009, at 4:41 PM, Adam R. Maxwell wrote:
>
> On Apr 7, 2009, at 2:59 AM, Christiaan Hofman wrote:
>
>> Adam, I've noted a few bugs in your fileview bindings.
>>
>> Most important is that that you're observing the wrong keyPath for
>> the
>> content binding ("content" is the name on the FileView, keyPath is
>> the
>> path on the observable).
>
> Heh, that was a fat-finger error that had some pretty serious
> consequences. Thanks!
>
>> Also, it's wrong to assume that the observed value is a proxy mutable
>> array. In fact, you should always copy the array and properly update
>> in the KVO observation
>
> That was my understanding as well, and was my original
> implementation. Since I was observing content instead of
> arrangedObjects, though, things like changing order didn't work
> unless I kept a pointer to the proxy array (or something like
> that...it was a long time ago).
>
>> Also you should not need to implement KVC accessors for
>> content.
>
> I don't think so either, but IB seems to call it (even if not
> calling super for the content binding).
Are you really sure it's not a side effect of some other thing? If
this is true it's a bug, binding names are not required to be KVC
compatible.
>> I think the problem with IB you note may have to do with the
>> fact that you don't update the value initially in -bind:..., I
>> usually
>> do that by explicitly calling a KVO observation from -bind:...
>
> I no longer recall that problem precisely, so I'll have to check it
> out...
>
>> Also, selectionIndexes could easily go through the default binding
>> mechanism, as it's a KVC compliant key.
>>
>> I think the self observation of selectionindexes is dangerous.
>> Updating a binding should never be triggered by the setter, you never
>> know what loops are there. It should always be similar to actions:
>> triggered by a user interaction. Moreover there's the
>> viewWillMoveToSuperview hack. I have done this by adding a private
>> version of setSelectionIndexes: that updates the binding and anything
>> that's needed, and use that internally.
>
> To what are you referring as a hack? Unbinding in
> viewWillMoveToSuperview? How are bindings unbound otherwise? In
> that case I think I was mainly following mmalc's example code.
Bindings should always be removed manually or using the nib (which
uses some special proxy to manage bindings).
> I've thought about something similar to what you suggest with
> respect to selection indexes, but never got around to it (I mainly
> didn't feel like debugging it).
I've got it implemented in the main bibdesk tree. It doesn't have the
IB plugin though, so I haven't tested that aspect. It even supports
value transformer options.
Christiaan
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
