Re: [Bibdesk-users] Improving compatibility with Dropbox when annotating PDFs

[Jeremy Van Cleve]

Hi all,

Like Graham, I have encountered this situation quite often when leaving 
BibDesk open on my laptop and then highlighting a PDF on my iPad. Once I 
sync my PDF collection back to Dropbox so that my highlights are 
available on my laptop, I often lose the link to the PDF in BibDesk.

While this is not a bug (as I was informed on the Dropbox forums where I 
complained about this), I agree with Andreas that the optimal solution 
would be a change in Dropbox behavior: for example, they could have some 
kind of single-user/non-caching flag that you could set on a per 
directory basis.  I'm sure this is not going to happen anytime soon (or 
at all), so I'm eager to try Graham's solution.

Best,

Jeremy

On 9/3/13 6:20 PM, Graham Dennis wrote:
> Hi Andreas,
>
> Dropbox's behaviour is a feature, not a bug.  Consider the following sequence 
> of events:
> 1. User opens file A.txt (hosted in Dropbox) on computer #1 and begins to 
> edit the document.
> 2. The same or different user opens the same file on computer #2, edits the 
> file A.txt and saves the file with the modified document.
> 3. Back on computer #1, the user saves their changes.
>
> The changes saved in steps #1 and #2 are in conflict, and it is desirable to 
> keep both changes to the document for the user to review and resolve later.  
> In this situation Dropbox achieves this by moving the file that the user was 
> editing on computer #1 into a private cache after the edited file from 
> computer #2 is downloaded onto computer #1.  If the file being edited on 
> computer #1 is saved, dropbox is able to detect this and move the conflicting 
> edit back into the Dropbox folder as a conflict file which the user can 
> resolve later.
>
> Neither is this a bug in Apple's code, so if this problem is to be fixed, it 
> must be fixed in BibDesk or with a solution like BibDeskWrapper.
>
>> Secondly, I'd like to remind us all that file linking/tracing as done by 
>> BibDesk is rather sophisticated and handles everything very well, including 
>> symbolic links and ordinary Finder aliases. It would be a pity, if any 
>> solution good for Dropbox would impact on any of these complex functions now 
>> very reliably handled by BibDesk. And I fear that may be the case. I am of 
>> course not sure whether that might be really the case or not, but fear there 
>> is a real risk. I do sync my bibliography files and pdf's among various Macs 
>> and iOS devices very well and encounter no problems nor glitches. I make 
>> sure on Macs that the file hierarchy is the same on all Macs (if necessary 
>> complemented with symbolic links) and use cloud services when syncing with 
>> iOS devices (my iPad, iPhone). I have never encou
>   ntered any difficulties in my workflow and I am happy with the reliability 
> by which BibDesk is handling all this. Of course, I need my own scripts to 
> accomplish this all conveniently. BTW, anyone interested can find all my 
> scripts also on my home page (http://www.sysecol.ethz.ch/people/afischli  
> link Software). All works very well right now, yet is sophisticated with 
> syncing back pdf's via symbolic links or Finder aliases via modification date 
> etc. I would hate if any of this would get disrupted.
>>
>> Sorry, for these words of caution, but I wish us all to consider all aspects 
>> before asking perhaps rashly for changes of BibDesk.
>
> I agree that caution is sensible.  The way BibDeskWrapper works means that it 
> will always be able to resolve a file when BibDesk can.  All that 
> BibDeskWrapper changes is which file is chosen when there are multiple 
> candidates.  If you rename a file A.txt (with contents A) to B.txt (still 
> with contents A) and then create a new file A.txt with contents C, then both 
> files are candidates to be resolved by BibDesk by a link to "A.txt".  The 
> current behaviour of BibDesk is that 'B.txt' (with contents A) will be 
> resolved if BibDesk was open while you made the changes, but 'A.txt' (with 
> contents C) will be resolved if BibDesk were not open.  BibDeskWrapper 
> changes this behaviour so that 'A.txt' (with contents C) is the resolved file 
> in both cases.  Of course if A.txt was renamed to B.txt and no ne
>   w file A.txt was created, then both BibDesk and BibDeskWrapper would 
> resolve to B.txt
>
> Regardless, my intention with BibDeskWrapper is to demonstrate (or find 
> otherwise) whether my approach is safe.  As I said, I agree that caution is 
> sensible, so testing of the suggested behaviour is a good idea before 
> implementing those changes in BibDesk.
>
> Best Regards,
> Graham Dennis
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.d

Re: [Bibdesk-users] Improving compatibility with Dropbox when annotating PDFs

[Fischlin Andreas]

Dear Graham,

I have not responded when you contacted BibDesk developers on this. But I wish 
to do this now by making two points:

First, I understand that this problem is annoying, however, I doubt it can be 
solved, or better, I do not think this should be solved by BibDesk. Rather this 
appears to be a problem Dropbox and/or Apple has first of all to solve. Given 
your wrapper solution works, I would consider this to be nearly ideal and would 
recommend to refrain from trying to fix in BibDesk a problem present in other 
software such as Dropbox or Apple's system software. This argument being made 
more on principal grounds of software engineering. Once Dropbox fixes this, one 
may have to change the code of BibDesk back to what it is now.

Secondly, I'd like to remind us all that file linking/tracing as done by 
BibDesk is rather sophisticated and handles everything very well, including 
symbolic links and ordinary Finder aliases. It would be a pity, if any solution 
good for Dropbox would impact on any of these complex functions now very 
reliably handled by BibDesk. And I fear that may be the case. I am of course 
not sure whether that might be really the case or not, but fear there is a real 
risk. I do sync my bibliography files and pdf's among various Macs and iOS 
devices very well and encounter no problems nor glitches. I make sure on Macs 
that the file hierarchy is the same on all Macs (if necessary complemented with 
symbolic links) and use cloud services when syncing with iOS devices (my iPad, 
iPhone). I have never encountered any difficulties in my workflow and I am 
happy with the reliability by which BibDesk is handling all this. Of course, I 
need my own scripts to accomplish this all conveniently. BTW, anyone inte
 rested can find all my scripts also on my home page 
(http://www.sysecol.ethz.ch/people/afischli  link Software). All works very 
well right now, yet is sophisticated with syncing back pdf's via symbolic links 
or Finder aliases via modification date etc. I would hate if any of this would 
get disrupted.

Sorry, for these words of caution, but I wish us all to consider all aspects 
before asking perhaps rashly for changes of BibDesk.

In any case many, many thanks for your wrapper solution.

Sincerely yours,
Andreas


ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

andreas.fisch...@env.ethz.ch
www.sysecol.ethz.ch

+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 595-4050 mobile

 Make it as simple as possible, but distrust it!








On 03/09/2013, at 08:49 , Graham Dennis wrote:

Hi,

There's an interaction problem between BibDesk and Dropbox which causes BibDesk 
to lose its link to files stored in Dropbox if those files are annotated on 
computer #2 while BibDesk is running on computer #1.  If you later save the 
library in BibDesk on computer #1, the link will be changed to a temporary file 
which will disappear in a few days.

I've reported this problem to the BibDesk developers, but they expressed 
concern that my approach to solving this problem might cause problems for other 
users if they have moved their PDFs.  Full details of the problem and my 
proposed solution are available here: 
https://github.com/GrahamDennis/BibDeskWrapper

If you're experiencing this problem and would like to help test my solution, 
please download BibDeskWrapper.app (http://bit.ly/18ewabY). BibDeskWrapper is a 
simple wrapper around BibDesk which modifies its behaviour to fix the problem.  
BibDeskWrapper and BibDesk can be updated independently, so using 
BibDeskWrapper doesn't prevent you from getting the latest updates to BibDesk.  
For information about getting AppleScripts to work with BibDeskWrapper see here 
(https://github.com/GrahamDennis/BibDeskWrapper#how-do-i-make-my-bibdesk-applescripts-work-with-bibdeskwrapper).


Regards,

Graham Dennis
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutor

Re: [Bibdesk-users] Improving compatibility with Dropbox when annotating PDFs

[Graham Dennis]

Hi Andreas,

Dropbox's behaviour is a feature, not a bug.  Consider the following sequence 
of events:
1. User opens file A.txt (hosted in Dropbox) on computer #1 and begins to edit 
the document.
2. The same or different user opens the same file on computer #2, edits the 
file A.txt and saves the file with the modified document.
3. Back on computer #1, the user saves their changes.

The changes saved in steps #1 and #2 are in conflict, and it is desirable to 
keep both changes to the document for the user to review and resolve later.  In 
this situation Dropbox achieves this by moving the file that the user was 
editing on computer #1 into a private cache after the edited file from computer 
#2 is downloaded onto computer #1.  If the file being edited on computer #1 is 
saved, dropbox is able to detect this and move the conflicting edit back into 
the Dropbox folder as a conflict file which the user can resolve later.

Neither is this a bug in Apple's code, so if this problem is to be fixed, it 
must be fixed in BibDesk or with a solution like BibDeskWrapper.

> Secondly, I'd like to remind us all that file linking/tracing as done by 
> BibDesk is rather sophisticated and handles everything very well, including 
> symbolic links and ordinary Finder aliases. It would be a pity, if any 
> solution good for Dropbox would impact on any of these complex functions now 
> very reliably handled by BibDesk. And I fear that may be the case. I am of 
> course not sure whether that might be really the case or not, but fear there 
> is a real risk. I do sync my bibliography files and pdf's among various Macs 
> and iOS devices very well and encounter no problems nor glitches. I make sure 
> on Macs that the file hierarchy is the same on all Macs (if necessary 
> complemented with symbolic links) and use cloud services when syncing with 
> iOS devices (my iPad, iPhone). I have never encountered any difficulties in 
> my workflow and I am happy with the reliability by which BibDesk is handling 
> all this. Of course, I need my own scripts to accomplish this all 
> conveniently. BTW, anyone in
 terested can find all my scripts also on my home page 
(http://www.sysecol.ethz.ch/people/afischli  link Software). All works very 
well right now, yet is sophisticated with syncing back pdf's via symbolic links 
or Finder aliases via modification date etc. I would hate if any of this would 
get disrupted.
> 
> Sorry, for these words of caution, but I wish us all to consider all aspects 
> before asking perhaps rashly for changes of BibDesk.

I agree that caution is sensible.  The way BibDeskWrapper works means that it 
will always be able to resolve a file when BibDesk can.  All that 
BibDeskWrapper changes is which file is chosen when there are multiple 
candidates.  If you rename a file A.txt (with contents A) to B.txt (still with 
contents A) and then create a new file A.txt with contents C, then both files 
are candidates to be resolved by BibDesk by a link to "A.txt".  The current 
behaviour of BibDesk is that 'B.txt' (with contents A) will be resolved if 
BibDesk was open while you made the changes, but 'A.txt' (with contents C) will 
be resolved if BibDesk were not open.  BibDeskWrapper changes this behaviour so 
that 'A.txt' (with contents C) is the resolved file in both cases.  Of course 
if A.txt was renamed to B.txt and no new file A.txt was created, then both 
BibDesk and BibDeskWrapper would resolve to B.txt

Regardless, my intention with BibDeskWrapper is to demonstrate (or find 
otherwise) whether my approach is safe.  As I said, I agree that caution is 
sensible, so testing of the suggested behaviour is a good idea before 
implementing those changes in BibDesk.

Best Regards,
Graham Dennis
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

[Bibdesk-users] Improving compatibility with Dropbox when annotating PDFs

[Graham Dennis]

Hi,

There's an interaction problem between BibDesk and Dropbox which causes
BibDesk to lose its link to files stored in Dropbox if those files are
annotated on computer #2 while BibDesk is running on computer #1.  If you
later save the library in BibDesk on computer #1, the link will be changed
to a temporary file which will disappear in a few days.

I've reported this problem to the BibDesk developers, but they expressed
concern that my approach to solving this problem might cause problems for
other users if they have moved their PDFs.  Full details of the problem and
my proposed solution are available here:
https://github.com/GrahamDennis/BibDeskWrapper

If you're experiencing this problem and would like to help test my
solution, please download BibDeskWrapper.app (http://bit.ly/18ewabY).
BibDeskWrapper is a simple wrapper around BibDesk which modifies its
behaviour to fix the problem.  BibDeskWrapper and BibDesk can be updated
independently, so using BibDeskWrapper doesn't prevent you from getting the
latest updates to BibDesk.  For information about getting AppleScripts to
work with BibDeskWrapper see here (
https://github.com/GrahamDennis/BibDeskWrapper#how-do-i-make-my-bibdesk-applescripts-work-with-bibdeskwrapper
).


Regards,

Graham Dennis
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users