Planned maintenance: From Sunday 8th December 10:00 CET there will be changes to try and solve the caching issues that have been experienced. If anyone has a problem connecting after this period then please PM @AndyS or any of the moderators.

Qt signal and slot internal connection details



  • [EDIT: Forked from https://forum.qt.io/topic/107901/what-does-it-mean-when-an-entire-function-is-a-slot --JKSH]

    @JKSH said in What does it mean when an entire function is a slot?:

    Signals are now be public; slots are unchanged.

    Yep, thanks, I had a funny feeling I was getting that the wrong way round :)

    I believe from reading the discussion about why the change (to do with the new signal/slot syntax, I believe), they never wanted to make #define signals public, but had to for compilation, so it's presumably good to regard/pretend as though it were still #define signals protected, i.e. never invoke signal from outside world.


  • Moderators

    @JonB said in What does it mean when an entire function is a slot?:

    so it's presumably good to regard/pretend

    All you can do is pretend as it doesn't really matter if a signal is public, protected or private. The meta-system circumvents these language boundaries and you can always call even a private signal of another class via invokeMethod().



  • @Chris-Kawa
    Yes, but the change was for the new connection syntax, not the "magic" of the old SIGNAL/SLOT() mechanism.

    I'm not a C++-er (I'm stinky Python/PyQt, where just about everything is public and everything can access everything else, lovely!), but I do like to understand how it's supposed to be from C++. So please correct me if I'm wrong, but:

    • In the new syntax, both signals & slots macros resolve to public.
    • This is required to allow the new, direct connect(signal, slot) from the outside world, code not in either the signal or slot classes.
    • To raise a signal you use emit(), and the emit part resolves to nothing, so it's just a straight call to the signal function.
    • In the old days you could keep signals as protected, so that only the signalling/emitting class could emit() the signal.
    • Now that signals has to be public, anybody could call the emit(), but Qt didn't really want that. So you are "politely requested" not to actually write an emit() unless you are inside the signal class, as that's how it is intended to be used.

    Please correct me if I have misunderstood.


  • Moderators

    I'm stinky Python/PyQt, where just about everything is public and everything can access everything else, lovely!

    Savages... :P

    Please correct me if I have misunderstood.

    Sounds right except for the part where previously only the owning class could call protected signal - as I said earlier, you could still call it (indirectly) via invokeMethod(). Anyway it's history and everything is public now, like in Python... <shivers>...



  • @Chris-Kawa
    Yes, but invokeMethod() is on QMetaObject, and that's what I refer to as the "magic" of the old ... (look up a string in a table of functions, rather than using language constructs). You have to pass a test before being allowed to use that, and your programming license will be revoked if you don't know what you are doing and get it wrong... :)


Log in to reply