On Dec 26, 2007, at 9:39 AM, Christiaan Hofman wrote: > > On 26 Dec 2007, at 6:26 PM, Adam R. Maxwell wrote: > >> Replying to the list since typing is easier in Mail. >> >>>> Comment By: Christiaan Hofman (hofman) >>> Date: 2007-12-26 18:28 >>> >>> Message: >>> Logged In: YES >>> user_id=1162009 >>> Originator: NO >>> >>> Perhaps we can use a dictionary of URL -> item (or perhaps >>> identifierURL) >>> rather than URL -> title in the file content search, and filter the >>> results >>> according to the selected group? >> >> I've thought about doing this for other reasons as well, but I no >> longer recall what they were, unfortunately. How would the UI work? >> Just filter the list based on the current group selection? >> > > I'd say so, similar to having groupedPublications and > shownPublications. Perhaps we could also move the items in the > selected group to the front of the list to index.
UI-wise, that would work, I think. Maybe the document could set a filter predicate on the file content array controller? Moving stuff around in the index would have to take place before the index is instantiated, so that would probably be difficult to do. > Though I don't > precisely know how the search objects work, I always get confused > when I look at those objects. Which objects in particular? I could comment them more thoroughly if that would help. Most of the code is just an Obj-C wrapper around the Search Kit functions, but it's complicated because we search the index while it's being created in another thread. Search Kit doesn't make that easy; I think the design is oriented towards searching after the index is fully created. >> On a related note, I've been planning to implement saving the index >> to >> disk, and the -identifierURL wouldn't work in that case unless we >> make >> it persistent (which might not be a bad idea), since that dictionary >> would have to be archived along with the index. >> >> -- >> adam >> > > Is it necessary to save the URL -> identifierURL? Couldn't this be > recreated when needed? Maybe. Right now it's created during indexing, when the relationship is known. To recreate it we'd have to iterate each SKDocumentRef in the index, copy its URL, then find a BibItem with that URL. > Perhaps we could even have an index that works > across bib files? I'm not sure that would be maintainable. On second thought, I'm not sure that saving the index at all is maintainable now. My plan for some months has been to check the BibTeX file's mod date against the index mod date, and recreate the index if they're different. We just made this problem unsolvable by introducing aliases, since now users can move things in the Finder without breaking the .bib file. I guess it could be worked around by checking the contents of the index against a set of all URLs in the document...but this may be more trouble than it's worth. > The problem of making the identifierURL persistent > means we'd have to save it in the bibtex. And what about external > items? I don't think external items should be included in file content search. I just noticed that weird view stuff happens if you select the web group while a file content search is active, though. -- adam ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
