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. >>> 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. > >>> 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 ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/skim-app-develop
