Home/ Questions/Q 8372633
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T14:28:57+00:00

Debugging signals and slots can be hard, because the debugger does not jump to

  • 0

Debugging signals and slots can be hard, because the debugger does not jump to the slots of a signal when it is emitted. What are some best practices for debugging Qt signals and slots?

In particular

  1. How do I make sure connections are set up successfully?
  2. When should I use signals and slots, when should I avoid them?
  3. What are the most efficient debugging techniques from your experience?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There was a blog post written a while back called 20 ways to debug Qt signals and slots
    It addresses I think #1 and #3 of your questions.

    For #2, I don’t think there is really a hard and fast reason to use or not use signals/slots, as they are a pretty core concept of the GUI framework. Signals are a perfect way to decouple the knowledge of one component to another, allowing you to design reusable widgets that simply declare state changes or notifications. It is also a very good way to communicate GUI changes from non-GUI thread loops, by emitting a signal that the main thread can see.

    There might be times where what you really want instead of a signal/slot is to use events, such as when a parent widget should become the event filter for a number of child widgets. The children still do not need to know about the parent, and the parent gets a more direct event as opposed to a signal connection.

    On the same topic of events, there are times where what you really want is a bubbling up of an event from child -> parent -> grandparent -> etc. Signals would make less sense here because they are not meant as a way to determine whether the proposed event should result in an action (they could be used this way obviously). Events allow you to check the current state, decide whether this widget should do anything, or otherwise bubble them up the chain for someone else to inspect.

    There is a really fantastic answer about The Difference Between Signals/Slots and Events. Here is a good snippet:

    • You “handle” events
    • You “get notified of” signal emissions

    What I like about that quote is that it describes the different need case. If you need to handle an action in a widget, then you probable want an event. If you want to be notified of things happening, then you probably want a signal.

    • 0