The only way I could see it ever being nil is if Omni or NSA screwed up in the
implementation :). I would assume (but haven't tested) that a zero length data
should return a valid hash, as it does with an empty file on the command line.
-[nil sha1Signature] would of course return nil in the case of no read
permission or missing file, in which case there's no point in even trying to
index it since Search Kit won't read it either.
On Friday, January 18, 2008, at 02:38PM, "Christiaan Hofman" <[EMAIL
PROTECTED]> wrote:
>I was wondering if the signature can ever be nil. The only reason nit
>could be nil if the data of the file could not be loaded. If it's
>never nil, we could also use the cached signatures dictionary to get
>all indexed URLs rather than iterating over the index. I think we
>could even do that when the signature might be nil, as we could then
>use [NSData data] as a placeholder.
>
>Christiaan
>
>On 18 Jan 2008, at 9:09 PM, Adam R. Maxwell wrote:
>
>>
>> On Friday, January 18, 2008, at 11:53AM, "Christiaan Hofman"
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On 18 Jan 2008, at 8:16 PM, Adam R. Maxwell wrote:
>>>
>>>>
>>>> On Friday, January 18, 2008, at 10:45AM, "Christiaan Hofman"
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>> On 18 Jan 2008, at 7:39 PM, Adam R. Maxwell wrote:
>>>>>
>>>>>> Another question: why not create a BDSKFileSearchResult per
>>>>>> identifier instead of passing the set to a BDSKFileSearchResult?
>>>>>> Or are the search result objects no longer used for display?
>>>>>>
>>>>>
>>>>> The search looks into and returns file URLs rather than
>>>>> identifierURLs. And there is no 1-to-1 correspondence. Any file URL
>>>>> (and therefore search result) can correspond to multiple pubs,
>>>>> and a
>>>>> pub can appear for multiple file URLs (results).
>>>>
>>>> Right, but I'm still confused. How are they displayed? There used
>>>> to be a 1:1 correspondence between rows in the table and
>>>> BDSKSearchResult instances. How are the multiple pubs displayed in
>>>> the table?
>>>>
>>>
>>> There still is a 1:1 correspondence between BDSKSearchResults and
>>> table rows. So rows correspond to file URLs rather than pubs (it
>>> always has). Each row can correspond to multiple pubs and each pub
>>> can correspond to multiple rows (the latter was already true, the
>>> first is new). In the past only an arbitrary pub was used. Now we use
>>> an arbitrary pub for the title, but e.g. editing will open all
>>> relevant pubs.
>>>
>>>> In BDSKFileSearch there is this:
>>>>
>>>> NSURL *theURL = (NSURL *)SKDocumentCopyURL(skDocument);
>>>> NSSet *identifierURLs = [searchIndex
>>>> allIdentifierURLsForURL:theURL];
>>>> NSString *title = nil;
>>>> NSEnumerator *idURLEnum = [identifierURLs
>>>> objectEnumerator];
>>>> NSURL *idURL;
>>>> while (title == nil && (idURL = [idURLEnum nextObject]))
>>>> title = [[self delegate] search:self
>>>> titleForIdentifierURL:idURL];
>>>>
>>>> searchResult = [[BDSKFileSearchResult alloc]
>>>> initWithURL:theURL identifierURLs:identifierURLs title:(NSString *)
>>>> title score:score];
>>>> [searchResults addObject:searchResult];
>>>> [searchResult release];
>>>> [theURL release];
>>>>
>>>> Based on previous recollection of the architecture it would make
>>>> sense to do
>>>>
>>>> for (identifier in identifierURLs) {
>>>> searchResult = [[BDSKFileSearchResult alloc] initWithURL:theURL
>>>> identifierURL:identifierURL title:(NSString *)title score:score];
>>>> [searchResults addObject:searchResult];
>>>> [searchResult release];
>>>> }
>>>>
>>>> I haven't followed all the changes in enough detail, so maybe this
>>>> isn't possible.
>>>>
>>>
>>> That's not logically possible. What is identifierURLs/theURL here?
>>> Also there can be several matched files for a single pub, so what URL
>>> and score to use?
>>
>> Use the same URL and score. I left out getting the title for each
>> identifier URL; it should have been
>>
>> for (identifierURL in identifierURLs) {
>> title = [[self delegate] search:self
>> titleForIdentifierURL:identifierURL];
>> searchResult = // create result with this file, identifier, title
>> }
>>
>> so you'd have the same file/score appearing multiple times in the
>> results, once for each pub it was associated with.
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> ---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Bibdesk-develop mailing list
>> Bibdesk-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Bibdesk-develop mailing list
>Bibdesk-develop@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
