On Dec 26, 2007 8:07 PM, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>
> 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.
>
I don't think it works with a filter predicate, then you need to hardcode
all the identifierURLs in the predicate, and it's probably slow. I think
it's easier to have a second filtered array or set, and update it when
needed.
> > 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.
>
Basically all objects. It's not clear to me what the role is of each object
(apart perhaps the window controller). Aggrevated by the fact that there are
two types of search indexes, with no way to distinguish where they belong
from the name.
>
> >> 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.
>
Why not the other way around: just create a URL -> item/identifierURL
dictionary from the items. The index does not need to know anything about
the items AFAICS (at least the results don't have a reference to the items).
>
> > 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.
>
I don't know, I think it could be worth it because indexing is pretty slow.
Perhaps we could check the URLs in the index and the items periodically as
well, to see if anything needs updating. Or at least when opening a cached
index.
>
> > 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
>
No, I mean what to do with identifierURLs in external items. Though probably
it's not an issue as we sure shouldn't cache any indexes for external groups
(or even have them at all, as you say).
Christiaan
-------------------------------------------------------------------------
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
