Don't have fam or gamin (for file change events) in use. But make sure that the desktop reflects these changes. Examples: Create a directory with right-click. Desktop shows it. (Good.) Right-click and delete. Desktop stills shows it even though doesn't exist. (Note that thunar itself doesn't have this problem.) Right-click and rename. Desktop still shows old name. Properties shows new name. On change, desktop should immediately reflect change -- no need to wait for fam. And on any highlighting of icon (hover over or click on icon), check for file status again and remove if needed. Maybe periodically check status of all known icons. Then overhead of fam/gamin is not needed. And maybe have an option to use libevent instead of fam or gamin.
No. This is a lot of special case code for questionable benefit. What's libevent? I thought that was a main-loop event framework library... I didn't think that had anything to do with file change notification.
I may be able to do some of the coding myself. I am reading through xfdesktop-file-icon-manager.c, xfdesktop-file-icon.c, and xfdesktop-icon-view.c. But I am not sure what causes the new icon to appear (even without fam) when created. Any pointers would be appreciated. As for libevent, it can watch file descriptors. Nevertheless, I think libevent, fam, gamin are overkill. Unless I am misunderstanding something. Seems like periodically watching desktop folder for stat changes is easy enough.
No, I just don't want those kinds of hacks in there. The current model doesn't at all *check* for file existence. Deleting and renaming files are *async* operations, so you can't just say "rename this to this and then it should be there so you can immediately stat() it," etc. Polling is bad. Period. We're not periodically polling the directory for file changes. libevent's file descriptor monitoring doesn't do what you think it does; it won't help us here. What is your issue with gamin or fam? They are both much nicer on your system then periodic polling.
Just to explain the bug again: create a directory and it appears, remove the directory and the icon still exists and can be moved and used. That seems like a bug. If fam/gamin is the expected way, then don't show the new icon on desktop when creating a directory. Then it would be consistent with adding a URL link, renaming, removing, etc. As for fam and gamin: fam has not been maintained in over five years -- numerous patches exist to fix its issues and to make it portable. And gamin developer's webpage says "... Gamin is fairly tied to Linux, portability is not a primary goal at this stage ..." (and I have seen reported portability issues and several patches not integrated upstream yet). For libevent it is lower-level. I have heard that some have patched gamin to use libevent. But I don't think libevent can watch file systems (just descriptors). Another tool that appears to be more portable is pnotify but still lower level. I guess my main problem is that fam is more overhead for extremely light/low resource systems.
Odd that the directory shows up at all without gamin/fam support. But it's been a while since I've looked at that code, so maybe there's a weird special case for it. Anyway, libevent is a non-starter. It's just not suitable or useful for this. If you can suggest another piece of file system monitoring software that works better and does NOT involve any kind of polling for status, I'd consider adding support for it. At any rate, that wouldn't happen before 4.8, and currently thunar is getting its guts ripped out in order to use the new gio/gvfs VFS layer rather than its own unmaintained thunar-vfs (which is what xfdesktop uses for all this stuff). So, xfdesktop will end up using gio/gvfs as well. If you want file monitoring support that works on NetBSD, you should check and see if gio/gvfs supports it, and, if not, work to get such support added there.
(Oh, by the way, you can hit ctrl+r to force the desktop to refresh the files.)