On Jun 5, 2007, at 04:23, Christiaan Hofman wrote:

>
>
> 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.
>
> Sorry, I mixed up some the different situations here.
>
> Deleting the file on disk indeed makes NSDocument lose its  
> connection to any file. So I guess we should also not try to watch  
> it for updates in this case, and remove it from the kqueue.

It should be removed from the kqueue at that point.  I didn't have  
time yesterday to mess with it any more, though, and I wasn't sure  
about save-as and save-to behavior.

> Moving the file on disk /is/ noticed by NSDocument, though with a  
> delay (e.g. when you select the window). So I think we should try to  
> watch the moved file. I'm not sure how, perhaps we could do that in - 
> setFileURL, because that is called when the document notices the  
> change on disk.

Ah, I don't think I tried that.  I tried re-adding it after a delay in  
the move/rename handler, but that only worked if I clicked on the  
document first.  I do agree that it should be watched automatically  
(although clicking Auto again isn't too painful).

If this kqueue business is too much hassle, I won't argue against  
reverting to a timer, either.

> Overwriting a file on disk is not noticed by NSDocument. By default  
> we should also not do that. The AS open command (or any file open  
> command) should not reload the file when it is already open and the  
> file on disk has changed. It can lead to data loss! Reloading the  
> (changed) file from disk is the responsibility of our file update  
> checking mechanism, and only that.

Definitely!  That's the autoReload BOOL ivar, right?  I actually have  
to write this week, so I'll be testing BibDesk and Skim.

-- 
Adam

-------------------------------------------------------------------------
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

Reply via email to