I have the solution, and it is potentially of general interest. It seems that the GtkPrintOperation widget is interacting with the (Unix) SIGUSR1 signal, which our program started using a while ago to do the client thing. Dropping the (unix) signal handler for that signal made the (glib) signals on the GtkPrintOperation widget start to work again. I don't know if that is documented anywhere.
Richard Shann On Mon, 2011-11-21 at 12:00 +0000, gtk-app-devel-list-requ...@gnome.org wrote: > Message: 4 > Date: Sun, 20 Nov 2011 16:13:57 +0000 > From: Richard Shann <richard.sh...@virgin.net> > To: gtk-app-devel-list@gnome.org > Subject: Signals that do not get emitted > Message-ID: <1321805637.2172.21.camel@debian2.myhost> > Content-Type: text/plain; charset="UTF-8" > > At one time we had the GtkPrintOperation widget working, sending > begin_print and draw_page signals; now it no longer works - the > callback > is never reached - and I wonder if anyone has some idea as to why that > should be. > It is not the specific bit of code that creates/launches the widget, > but > something more generic (like disabling a class of signals, if such a > thing is possible). I say this because I only came across it when I > installed a widget from libevince which uses the GtkPrintOperation and > that fails to get the callbacks. > I have built the evince widget as a standalone program (see below) and > it works. But the same piece of code called from within our (large) > program does not. > > This has been seen in Gtk 2.30.2 and also in Gtk-3 (not sure which > version). > > Any ideas how this can happen? (the project is Denemo, www.denemo.org, > and the file concerned is print.c). _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
