> You have to find you what dv is, where is is constructed and > how to pass it where you set up the notify handler.
DirView * dirview_create (const gchar *root_dir, GtkWidget *parent_win, GimvThumbWin *tw) { (...) dnotify is being slowly overtaken by inotify but some of the kernels I run across are older and won't have it in there. I also don't mind the single directory, non-recursive, because that's all I need for this. > It could look like: > > dv = ... set up the dir view ... > /* And here comes your part */ > setup_notify(dv, &refresh_me); Okay, I understand the setup_notify and the dv there, what's the refresh_me for (do?) or is that just another call to the function you have listed below? What would the call to create the setup_notify be? I'm already using int change_notification(void) So, that would be int change_notification (dv, &handler) { DirView *dv; struct sigaction act; int fd; (...) and above that would be: static void handler(int sig, siginfo_t *si, void *data, DirectoryView *dv) { event_fd = si->si_fd; cb_refresh_dir_tree(dv, NULL); } > > Where setup_notify() remembers dv, the function to call on > it, sets up the dnotify() notification (is dnotify() still > the preferred mechanism? I recall rumours of it being about > to be replaced from approx. 2 years ago) and does something > like > > g_signal_connect(dv, "destroy", G_CALLBACK(stop_notifying), NULL); okay, g_signal_connect to dv, signal name, callback of stop notification, and data returned (none). So, this is where I need to put the listener (dnotify())? I would like this to go on the entire run of the program. I guess, what's the "destroy" for? > > where stop_notifying() is a function to shut down > notification for dv and forget dv. And refresh_me() just > does > > static void > refresh_me(DirView *dv) > { > cb_refresh_dir_tree(dv, NULL); > } That's the handler() up there. > > I don't know what the lifetime rules are for the directory > views or whether more of them can be present, but this > scheme can work quite generally. You can employ a more > general callback mechanism, but this should be sufficient in > your case. I'm getting there. I understand what I want to do, I'm just relearning how C makes me say it. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list