On 6/5/07, Christiaan Hofman <[EMAIL PROTECTED]> wrote:
On 6/5/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>
>
> On Monday, June 04, 2007, at 04:03PM, "Christiaan Hofman" <
> [EMAIL PROTECTED]> wrote:
> >On 6/5/07, Adam R. Maxwell <[EMAIL PROTECTED] > wrote:
> >>
> >>
> >> On Monday, June 04, 2007, at 03:43PM, "Christiaan Hofman" <
> >> [EMAIL PROTECTED]> wrote:
> >> >When the file is deleted, the kqueue notification is broken. So some
>
> >> >atomic writing processes can give problems. How can this be fixed?
> >> >Should there be a timier for this case?
> >>
> >> I'm not sure how many ways it can break, but I tried this:
> >>
> >> 1) run LaTeX on test.tex from TextMate, opens test.pdf in Skim
> >> 2) in Terminal, rm test.pdf
> >> 3) switch back to Skim; proxy icon for test.pdf is now gone, but the
> >> window is still there
> >> 4) switch to TextMate, run LaTeX again, and the window for the
> deleted
> >> test.pdf comes to the foreground
> >>
> >> I'm not sure how to handle that case. The kqueue notification is
> removed
> >> now when the file is deleted or renamed, but it seems like the "open
> POSIX
> >> file" in displayline isn't handled correctly by NSDocumentController,
> since
> >> (IMO) it should be opening the newly created test.pdf file. Just
> renaming
> >> test.pdf to test2.pdf and then re-running latex works as I expected,
> >> though.
> >>
> >> Adam
> >
> >
> >Opening a file shouldn't do anything if the file is already open, even
> if
> >the file has been updated. That's just normal opening procedure of
> >documents. So I do think this behavior is basically correct. Also
> because
> >the script doesn't know about updates.
>
> That doesn't seem like expected behavior to me. If I delete a file and
> then switch to Skim, the window no longer has a proxy icon, so presumably no
> longer has a path on disk; if you hit cmd-s, it says the location can't be
> determined.
If I recreate a file on disk at the same path and then tell the app to
> open it using the full path, I expect it to open the new file, not switch to
> the window for a file that it just told me no longer exists. Preview does
> the same thing, but it seems broken.
Generally it is. Remember, Skim is a viewer, so it views what you have
loaded. This is the way open document works. Also if you open a document
e.g. by double-clicking. It does not change to a changed file. So it is
standard NSDocument behavior.
>However the file update checking
> >should reload the file in this case, and that's what I'm talking about.
> So I
> >think we should run a timer when the file is deleted to see if the
> file
> >comes back, because kqueue is useless in that case.
>
> Yeah, that's probably the only way to reload it. Although I'm not sure
> if that's correct either, based on the behavior I just described; maybe that
> document should just stay in limbo until it's closed, if we want to be
> consistent with Apple's behavior.
>
> adam
>
> But this is not about opening a file, but about updating a file, so
about observing file changes (for which the user has opted in, so it should
expect to work that way).
BTW, saving (in particular save as) breaks the kqueue. The observation
needs to be removed
before saving, and restored if necessary afterwards.
Christiaan
Another problem for kqueue. The file name can change. If you move the file
on disk, NSDocument will notice this and change its file name. It seems to
be using an fsref internally, rather than just an NSURL. It has some private
methods like _setFileSpecifier, _fileLocator, and
_resetMoveAndRenameSensing.
Christiaan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
skim-app-develop mailing list
skim-app-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/skim-app-develop
