From: Adam R. M. <ama...@ma...> - 2007-10-27 18:07:40
|
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 >> Bib...@li... >> 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 > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop |