On 04/01/2017 01:04 PM, cecas...@aol.com wrote: > > Hi David, > > Not sure about this one. I tested some code out to see if I could figure it > out. Had the same problem that you had with the "changed" signal not being > blocked. If I change the rate of the file monitor and try to spool out the > events, I can block the "changed" signal. Not something that I would recommend > doing outside of testing so I suspect there is a better way to go about it. > Blocking the "changed" signal isn't going to solve the problem of knowing > where the change is coming from which can come from another process at any > time. Maybe if you had a pid in the "changed" callback, then you could compare > it with your program pid to see if the change is coming from your program or > someplace else. > > The following is what I tried using gedit and the terminal. Hopefully you get > some better ideas. > > Eric >
Thank you Eric, I will tinker with what you have tried and see if I can figure out more how GFileMonitor signal handling is different from default GTK. I've gotten some suggestions on StackOverflow, but more simply confirm your and my findings. Since GIO handling of the emission and blocking of "changed" is a big black box without picking though the source code, there are suggestions to just save the file 'stat' information and compare against any changed signal for foreign modification and setting a 'save' flag to ignore the "changed" signal during normal file saves. It's frustrating that the GFileMonitor "changed" signal handler block doesn't follow the normal block/unblock convention based on 'instance' and 'handler_id' alone. That certainly would provide a much more elegant solution. Worse case, I can always resort to the original 'inotify' implementation as the custom signal works fine with block/unblock. I'll just have to play with invoking the read from pselect with a g_idle_add of the callback that does that. I haven't played with that yet (as I've been chasing my tail on the GFileMonitor issue in spare time). -- David C. Rankin, J.D.,P.E. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
