On 12 Aug 2008, at 11:29 AM, Tony Sloane wrote: > Hi everyone, > > This message is to see if the Bibdesk developers are interested in > adding some support to Bibdesk to enable better interaction with a > particular e-book reader. Feel free to ignore if this is something > that doesn't interest you. Apologies for the length of the message, > but some detail needs to be explained. >
No present developer is interested in adding support. Well, I speak for myself, but I'm the only active developer ATM. > I'm a long-time BibDesk user on Mac OS X who is now using an iLiad e- > ink device (see http://www.irextechnologies.com/products/iliad) for > reading research papers. I have a master document folder on the Mac > which Bibdesk maintains for me. I synchronise that folder onto a CF > card that the iLiad can use. > > There is a hitch, however, due to the way that the iLiad deals with > documents. Suppose you have an auto-filed document called doc.pdf > (the folder doesn't matter). This file will show up in the file > browser on the iLiad to be selected for reading. When the document is > opened, the iLiad changes the file structure to be as follows: > > doc.pdf/doc.pdf > doc.pdf/manifest.xml > doc.pdf/scribble.irx > Now this is seriously bad behavior of iLiad, I would say buggy. They hijack the standard PDF file type and make it into a package. They should have defined their own file type with their own extension, as Skim does. > > I.e., the file is replaced by a folder with the same name, containing > the original document, plus some extra iLiad-specific files. The > extra files are used by the iLiad to remember reading position, record > annotations, etc. This is all transparent to the user of the iLiad > (i.e., the file browser still just shows doc.pdf). > > Obviously this file structure change causes problems for Bibdesk. It > is no longer possible to open doc.pdf from within Bibdesk since the > link points to a folder. It would be great if Bibdesk knew about this > alternative file structure and was able to transparently present the > linked file whether or not it had been moved. > In principle BibDesk has no problem with packages, as demonstrated by Skim's PDF bundles. You can just link a folder or package in BibDesk. And for opening, BibDesk just asks the system to open the linked URL with whatever is the default application for the file type. The problem is probably because the system is confused about the file type, because of iLiad's buggy file type. > I have some patches that seem to be working, but, although I'm a > coder, I wouldn't vouch for my Objective C skills and I'm not at all > familiar with the Bibdesk code base. My changes seem to correctly > handle the redirection when opening a linked file and moving all of > the right things when an entry is refiled. I've been using the > modified version for a few months with no problems that I can see. > > Anyway, please let me know if you are interested in this > functionality. I realise that it's not of mainstream interest, but > the changes are relatively small, I think, so they shouldn't have a > great effect on the rest of Bibdesk. I'm happy to pass over my > patches and work with you to test changes etc. > > I've joined the bibdesk-develop list for the moment, so responses can > just go there. > > regards, > Tony Sloane Can you send/attach your patches, so i can review them? BibDesk's linke dfile handling is particularly non-trivial, as it should be be doing the right thing in a wide variety of situations. Christiaan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bibdesk-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
