I can sympathize with the DT developers. They're being asked to support something that is a) subject to change without notice (Skim's note format) b) does not have support of a company to ensure future development and c) would require fair amount of code, at least for full note display.
Just displaying the notes or adding them to a search index is pretty easy, but there are some subtleties with extended attributes. For instance, you'd have to keep a checksum of the EA data itself if you use a persistent search index, which I assume is what DT does. BibDesk sidesteps this by rebuilding the index whenever a database is opened, and observing Skim's save notifications for updates. -- adam On Mar 28, 2008, at 8:15 AM, Michael Singer wrote: > Michael, > > Yeah -- the search engine is hit and miss. Glad Eric seems to have > fixed it. > > Thanks for posting the summary. It's clear there's a lot of folks > struggling with improving the integration. > > And I totally agree with your last post on the DT forum. > > Michael Singer > > >> Michael, >> >> I'm not surprised you failed to find the threads on the DEVONthink >> forums concerning Skim as the site's internal search engine is >> decidedly hit and miss. There has been quite a head of steam >> building up on those forums from Skim users - almost obviously >> because those of us who read a lot of pdfs will be drawn to Skim - >> and to DEVONthink as the database. From your post over there >> Michael (excellent btw) I expect you've now seen the discussion, >> summed up by someone on those forums six months ago writing: >> >> "[DEVONthink] heralding itself as the premier content and document >> data manager MUST be able to access text entered in PDF files, both >> through Preview and Skim. This is a basic reqirement in this age. >> (And I believe EagleFiler can handle this task.) This is one more >> example of limited handling of metada" >> >> To save everyone a lot of reading, the consistent DT response over >> the last six months has been threefold. First, decidedly sniffy, >> unfairly disregarding Skim as a proprietary format. Second, to >> leave one assuming 'the developers' are aware and working on a >> solution (probably their own alternative), though as someone in >> their forums stated, it's been a long, long wait [don't we just >> appreciate Christiaan's responsiveness?] and third, the project >> lead Eric Boehnisch has just linked to a suggested workflow, an >> approach that requires a disciplined, systematic, organised... well >> lets just say the no fuss, drag and drop approach to handling Skim >> pdfs _and_ their notes of BibDesk or Eaglefinder stand as >> commendable examples of what is needed, and needed now. >> >> There's clearly a lot of folk like me with a large DT database of >> pdf's but not sure how best to integrate with Skim. >> >> http://www.devon-technologies.com/scripts/userforum/search.php?keywords=skim&search_terms=all&search_forum=-1&search_time=0&search_fields=all&search_cat=-1&sort_by=0&sort_dir=DESC&show_results=topics&return_chars=200 >> >> Michael > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace_______________________________________________ > Skim-app-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/skim-app-users ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Skim-app-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/skim-app-users
