On 8 Jul 2007, at 1:00 AM, Adam R. Maxwell wrote: > > On Jul 7, 2007, at 14:42, Christiaan Hofman wrote: > >> >> On 7 Jul 2007, at 11:24 PM, Adam R. Maxwell wrote: >> >>> >>> On Jul 7, 2007, at 14:11, Christiaan Hofman wrote: >>> >>>> >>>> >>>> On 7/7/07, Christiaan Hofman <[EMAIL PROTECTED]> wrote: >>>>> >>>> I think I found the problem. It's something I was unsure about >>>> earlier but forgot about. The notifications are registered for the >>>> file path as the object. That's wrong, as the object is compared >>>> using pointer equality, /not/ isEqual. >>> >>> Yeah, I forgot about that implementation detail (which Apple >>> ought to >>> document). How about just registering for nil and comparing the >>> path >>> from the notification's userInfo? >>> >> >> That's why I made the following remark: we want to be notified when >> the file name has changed, but them of course the file name has >> changed... >> >> Anyway, it's wrong to use a string as the sender, it must be a >> controller object. > > I don't think it's wrong...it's just not very useful because > NSNotificationCenter has an un-Cocoa implementation. It's also not > obvious from the selector names, especially if you only look at the > NSNotification API. >
It leads to unexpected results, and very hard to figure out. I call that wrong. >>>> I'm not sure how to fix this >>>> though, as the fileName of the document can change when the >>>> file is >>>> moved or deleted, while we should still observe those changes. Also >>>> UKKqueue does not ensure that it always uses the same instance for >>>> the notification name, so it's also wrong. >>> >>> UKKqueue always uses the original file path pointer for the >>> notification, as passed in. >>> >> >> Not when the file was already watched, it then uses the previously >> registered one. > > Isn't move/delete handled by setFileURL:, though, instead of the > kqueue notification? It should be removed and added again in that > case, but I forget now why that code is there. Using -fileName as the > notification center object still isn't going to be reliable, though. > Partly. One problem is that setFileURL is called with a significant delay. Also, when the file is deleted, the notification has to be removed. As the kqueue notification and the setFileURL: are not synchronized we cannot rely on the fileName being the correct one corresponding to the kqueue notifications. When the file moves, we don't need to remove/add, because both the document and the notification work with file specifiers in the end, and those do not change. For a delete, we do need to remove the kqueue observation. We shouldn't re-add because the document will have lost it's connection to a file anyway. >> >>>> Is it much of an overhead to have one UKKqueue for each document? >>> >>> Not really. It does create another thread, but there's very little >>> memory overhead AFAIK. >> >> I think we should go that road. > > It would be nice not to create a thread for every file that's opened. > There should be a more elegant way (but I can't think of any). What > about using the document to store previous file name in case of a > rename? > > -- adam That's a possibility. I now implemented it with separate UKKQueues, which works. Note that we also use separate threads already for pdfsync. And the number of documents is still rather limited. 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
