@grant_h @caseyliss Signals and slots are a more formal, managed, and anonymously targeted form of "callbacks". In their simplest use cases, they just communicate that some event happened, e.g., "we connected to the database", "the user saved", etc. As you go deeper, you might include data: the mouse coordinates and modifier keys when you are notified of a click. You decide, when you make a brand-new kind of signal, what you are telling the world and also what data they need along with that to be able to take the kinds of actions you think might care. The code actually doing the work (e.g., connecting to the database) always "emits" the signal. That's basically no work at all if no one is listening. As many clients as you have can connect to that signal (emitting that signal calls some destination "slot"). The database-opening code doesn't know anything about the slot-providing clients. The slot-providing clients don't know any of the internal details of the database-opening code. The idea that you can be notified ... that there **is** an available signal ... that's now a part of your public API.