Re: How to get id of/remove a default handler?

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:
in which I can place other elements. Every time an elements is placed in a
bin an "element-added" signal is emitted:
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:
Sent from the Gtk+ - General mailing list archive at

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]