Much of it the ideas come from mmalc's GraphicsBinding sample project
<http://homepage.mac.com/mmalc/CocoaExamples/controllers.html>.
The void* stuff is rather innocuous. These are just context tags to
identify the bindings. The context is just a pointer size variable,
so a small integer is never a problem. It could also be a pointer to
an object (e.g. a string), but then those should be retained globally.
Note that I didn't do the image cache updating, as I don't know how
that works.
It could be combined also with the editing stuff (inserting/removing
URLs). I think it should try the following for insert/remove (replace
is just remove+insert):
1. check if we're editable
2. if editable, try dataSource methods
3. if no dataSource methods, try content binding, get the object
using a delegate method -fileView:newObjectForURL: or something, and
insert/remove using mutableArrayValueForKey: using
infoForBinding:@"content"
4. if no content binding, try contentValue binding, here we could
directly insert the URL
5. otherwise, ignore the edit
This would allow the datasource/delegate to only implement -
fileView:newObjectForURL:.
So the Leopard stuff is only relevant for the previewer then? How
does it work on Tiger?
Christiaan
On 27 Oct 2007, at 8:11 PM, Adam R. Maxwell wrote:
>
> On Oct 27, 2007, at 6:13 AM, Christiaan Hofman wrote:
>
>> You could use this code.
>
> Wow. That's cool, and it's pretty complicated...how much of it
> documented vs reverse engineered? The first thing I saw was the int-
>> void* magic numbers, and I don't want to introduce OS version
> compatibility issues unless I understand the code :).
>
> Anyway, I'll put FileVew out for public ridicule soon, although it
> needs better design documentation. Everything compiles on 10.4 except
> the Leopard bundle that needs to link against the QuickLook framework.
>
> adam
>
>>
>>
>>
>> <FileView_Bindings.m>
>> On 26 Oct 2007, at 4:20 PM, Adam R. Maxwell wrote:
>>
>>>
>>> On Oct 26, 2007, at 05:59, Christiaan Hofman wrote:
>>>
>>>> At the moment we don't use the FileView bindings. I don't think it
>>>> is
>>>> possible, as the URLs are not the same as the real underlying
>>>> objects.
>>>
>>> Did you remove the bindings in BibDocument, then? I thought that
>>> was
>>> still using an array controller.
>>>
>>>> So perhaps to make it possible to bind to the underlying
>>>> file objects *and* the URLs, we could do something like
>>>> NSPopUpButton: a "content" binding and a "contentValues" binding.
>>>> "content" binds to the array of file objects (or more properly, the
>>>> arrangedObjects of an NSArrayController binding to the array of
>>>> files), and "contentValues" binds to the same key path with the key
>>>> for the URL value appended (so to arrangedObjects.fileURL, or
>>>> perhaps
>>>> arrangedObjects.displayURL to allow for dummy URLs when the file
>>>> does
>>>> not exist). This also allows to build in adding, removing, and
>>>> moving
>>>> files.
>>>
>>> Hmmm...I never bothered to figure out NSPopUpButton's binding. So
>>> content is bound to an array proxy, and it uses contentValues to get
>>> the rest of the key path? I'm not sure what that would look like in
>>> code; would it require adding another array ivar?
>>>
>>> Bindings are already sort of wedged in on top of the datasource
>>> stuff,
>>> and I'm definitely hesitant to do something like a complete rewrite
>>> at
>>> this point and throw out the last 4 months of testing and
>>> profiling :). Right now it looks like this:
>>>
>>> // KVC setter/getter iconURLs changes _iconURLs ivar
>>>
>>> - (NSURL *)iconURLAtIndex:(NSUInteger)anIndex
>>> {
>>> NSURL *aURL = [[self iconURLs] objectAtIndex:anIndex];
>>> if (nil == aURL)
>>> aURL = [_dataSource fileView:self URLAtIndex:anIndex];
>>> if ([[NSNull null] isEqual:aURL])
>>> aURL = nil;
>>> return aURL;
>>> }
>>>
>>> - (NSUInteger)numberOfIcons
>>> {
>>> return nil == _iconURLs ? [_dataSource
>>> numberOfIconsInFileView:self] : [_iconURLs count];
>>> }
>>>
>>> So internally everything just calls iconURLAtIndex: and
>>> numberOfIcons:
>>> instead of accessing the _iconURLs ivar or messaging the datasource
>>> directly.
>>>
>>>
>>> --------------------------------------------------------------------
>>> -----
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Bibdesk-develop mailing list
>>> Bibdesk-develop@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
>>
>> ---------------------------------------------------------------------
>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Bibdesk-develop mailing list
>> Bibdesk-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Bibdesk-develop mailing list
> Bibdesk-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
