[Interest] Signal/Slot connection fails, even though QMetaObject::activate is called

[Max Paperno]

Hi Matthew,

On 2/17/2020 4:27 PM, Matthew Woehlke wrote:
> On 15/02/2020 00.40, Max Paperno wrote:
>> To me this says that you specifically want the connection to be
>> destroyed when the `context` object goes away, in case the sender and
>> receiver/context objects aren't the same for some reason.
> 
> The sender and receiver/context are *rarely* the same... that would be a
> self-signalling object.
> 
> You probably meant that they *share lifetime*, 

Well, no, I did mean the same object (shared lifetime can be dubious, I 
agree). But you're right, a rare situation, especially in 
well-designed/robust object code. Maybe for a QueuedConnection, but that 
of course would require the 5-argument overload anyway (or just using a 
queued QMetaObject::invoke(this, ...) in the first place).

But for example a simple button subclass which does something internal 
(change color, show a message, self-destruct :-P ) when pressed... so 
one could just connect to the clicked signal in the c'tor and do 
something "self-contained" which doesn't affect anything besides itself. 
Yea... I'm probably reaching here.

On 2/17/2020 4:27 PM, Matthew Woehlke wrote:
> On 15/02/2020 00.40, Max Paperno wrote:
>> Seems clear that for objects in different threads the sender and
>> receiver/context wouldn't be the same, hence the connection type
>> parameter in that overload.
> 
> Sure, but the connection type has other uses. 

Of course. Explicitly queued can be very useful, I agree.

Cheers,
-Max