Thank you Yeti for you reply. Now I can see that I should've added some context to my questions.
What I mean by a default handler is a piece of code that gets executed when an object emits a signal, and which code you don't have to write yourself but is there, somewhere already (as opposed to a custom handler that I'd attach to an object with g_signal_connect()). I am currently playing with GStreamer framework, where I create elements that emit signals in response to particular situations, e.g. disconnection from other elements. Then a thing that I call "a default handler" catches those signals and does something accordingly. For example, I can create an element of type GstBin: [ http://gstreamer.freedesktop.org/data/doc/gstreamer/stable/gstreamer/html/GstBin.html ] in which I can place other elements. Every time an elements is placed in a bin an "element-added" signal is emitted: [ http://gstreamer.freedesktop.org/data/doc/gstreamer/stable/gstreamer/html/GstBin.html#GstBin-element-added ]. Now what I want to do is to block/freeze/temporarily disable the handler that is about to get executed, or hijack the signal. I've just stumbled across g_signal_override_class_handler () method which seems to be sort of what I'm after... I'll try that tomorrow (-: David Nečas (Yeti)-2 wrote: > > On Fri, Jul 31, 2009 at 06:24:37AM -0700, machinegodzilla wrote: >> >> I created an object that emits different signals depending of what has >> happened. I know the names of those signals. Now I'd like to have some of >> the signals not to be emitted from time to time. To do that I need to >> block/disconnect specific handlers. However, the methods to do that >> require >> handler ids to be passed as arguments. >> >> How do I get ids of default handlers? Or maybe I need to do it some other >> way in this case? > > The class closue (if you mean that by default handler, i.e. the method > passed to g_signal_newv()) is not a handler hence, it has no id and > cannot be blocked by the blocking functions. > > If the class closure is of the run-last kind, you can do many things > such as using the accumulator mechanism (similarly to Gtk+ handling of > events) or stopping the signal emission in your own signal handler. > > If it runs first there's not much you can do to prevent it from running. > > If you do not want the signal emitted at all then simply don't emit it. > I suppose you wrote the class so you can use some flag to tell the > objects to avoid the emission and that not invoking the class closure is > safe. > > If you didn't write the class then preventing the class closure from > running is not a good idea because it can bring the object into an > inconsistent state and Bad Things will happen. > > For property notifications, you can also use the freeze/thaw mechanism, > providing that you are willing to let the handler run later. > > Or you can make the handlers smarter so they avoid the unwelcome action > themselves. > > Hard to tell without knowing *why* you want to prevent the signals from > being emitted... > > Yeti > -- View this message in context: http://www.nabble.com/How-to-get-id-of-remove-a-default-handler--tp24755772p24764068.html Sent from the Gtk+ - General mailing list archive at Nabble.com. _______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
