#1050 Better handling of Dropbox problem
Issue #1021 was closed as won't-fix for technical reasons: Dropbox makes it impossible to know which version of the file should be followed, and it would be wrong to load the wrong one. Dropbox won't change this. Given the existing knowledge about this, I assume I'm not the only one experiencing this as s problem, so perhaps we could try to find a solution that addresses user needs, in other ways than the obvious route? (I assume that the fact that Apple's Preview is able to do this kind of reload is irrelevant -- i.e., either they do the wrong thing, or Skim is unable to replicate their behavior. Which is fine.) Perhaps some feature or other could be added to make a Dropbox-based workflow easier? I make some comments in #1021, but that was after it was closed, which may be why they are ignored. Basically, all I want is the ability to easily reload a file without losing my place.
Currently, I can reload a file by closing it and then selecting it again from the "open recent" menu, or simply based on its path (in the Open dialog). This information is clearly available in/to Skim. This, however, loses my place -- it scrolls back to the beginning, and zooms out. Avoiding this is the original reason I chose Skim over Preview.
When Skim automatically reloads a file, it manages to keep its place, including scroll/zoom. Which is what I would like.
So: The information and capability is available in Skim -- it's just not available to the user. Could it be? The following is one way of attacking it (though some form of automatic reload like in Preview would clearly be more convenient -- e.g., by asking Skim to identify files by path, for example):
Main feature request: The ability to manually reopen (as is possible now) without losing my place.
Secondary feature request: The ability to manually reopen with a single menu item or AppleScript command.
Not sure this is relevant, but: An interesting part of this is that what I really want is a reload when I rebuild the PDF using pdfLaTeX. So I don't even really need a reload of a file synced via Dropbox. Just want the local sync to keep working, even if the file has temporarily been synced, and is then overwritten locally. Not sure what it is that Dropbox does to interfere with that…
As bug # 1021 says, we cannot fix this. The way drop box works makes it impossible for an external app to know which file is the "real' file, that just is not well defined. Therefore we cannot follow it anymore. Trying anyway will lead to inconsistencies, which leads to more and more serious problems later on. Therefore we keep it safe: do nothing.
So we cannot implement this feature, because we don't know where to find the file to reopen, neither automatically nor manually.
I understood the reasoning for closing #1021 -- this is not the same issue. When you say "we don't know where to find the file to reopen, neither automatically nor manually," I'm not sure what you mean, as Skim is already able to reopen the file manually. The issue is that when I do so, it loses its place. But I see you're not interested in pursuing this, so I'll have to solve the problem in some other way. Thanks for your attention, though.
No, you can reopen "the" file manually, by ooking it up in the file system. We can't, because we don't know what the file is. There are really two files, and we have no way to know which is the one you want to call the file. In fact, there is a large probability Skim has already forgotten about the file that you think is the file, because we have no guarantee to have any reference to that file. So the chance is big (close to 100%) that when we would reopen the file, it would not be the file that you think is the file.
Right. I'm sorry if I'm muddying things or coming off as standoffish or anything. I merely meant that it was already possible to manually reopen a file by closing it and then selecting it again from the "open recent" list (i.e., the "manual" part), something which I assumed could be done with a simple keyboard shortcut. But I do understand that it requires identifying the file in that list, which I guess is not feasible. The main issue is really that I lose my place in the file when I do so. But if you can't recognize the file as being previously opened, I see how you can't store scrolling info. That just surprised me, as the file is available in the "Open Recent" list, but I guess there's more magic going on there than I know about. As I think I pointed out earlier, I'd be happy with any kind of hook that would let, say, reload based on the path the file was originally opened with, but I guess it's a bit hackish. Which is what I meant by you not being interested in pursuing this -- i.e., it requires some solution that doesn't use the specific technology that's standing in the way. And I understand why you wouldn't want that. I can just write something myself, or work around it by copying my files out of Dropbox in my Makefile, for example.
Huh. Even quitting and then restoring previous session works (except for the scrolling).
But, yeah, lacking some built-in reload functionality like "restore previous session", here's a script that at least does roughy what I need -- in case someone else needs the same thing. The only thing I couldn't figure out right now was preserving horizontal/vertical scroll inside a given page, but I guess that's not too crucial.
tell application "Skim" set win to the front window set wbnds to the bounds of win set doc to the document of win set fname to the path of doc set theview to the view settings of doc set thepage to the current page of doc close doc open fname set win to the front window set the bounds of win to wbnds set doc to the document of win set the current page of doc to thepage set view settings of doc to theview end tellI guess an alternative might be to simply have a script that quit, restarted and restored the previous session.