[Development] Proposal to change connectSlotsByName behavior

André Somers andre at familiesomers.nl
Fri Dec 4 09:01:26 CET 2015

------ Original Message ------
From: "Thiago Macieira" <thiago.macieira at intel.com>
To: development at qt-project.org
Sent: 04/12/2015 03:00:15
Subject: Re: [Development] Proposal to change connectSlotsByName 

>On Friday 04 December 2015 00:27:09 Olivier Goffart wrote:
>>  I don't think it will break too many applications because anyone who 
>>  relying on the order of instentiation for that has just its 
>>  working out of pure luck. (And i'm pretty sure that your proposal is 
>>  the intended behaviour)
>Note that for widgets, the order is not pure luck. The order of 
>children of a
>QWidget implies the tabbing order. Therefore, it is usually 
There are explicit methods for setting the tab order. Relying of the 
order of creation (which may be the default tab order - I did not check) 
is also pure luck, especially with designer-created UI's. I would think 
the connect-by-name is more used with designer created UI's than with 
hand-crafted UI.

>I don't mind changing the order, as long as there's a consensus in the 
I am for it. I think it makes more sense than the current behaviour.

>If we do decide to change the order, I have a follow-up question:
>  do we change it only in connectSlotsByName, or do we change
>  QObject::findChildren to reflect the new order?
Both. A breath first search makes sense there as well. I don't think the 
order of the children is specified there so one should not rely on it 

>Right now, connectSlotsByName simply uses findChildren's order. If we 
>decide to
>change the order in one but not the order, I'd like to hear a 
>reason why it's ok for them be different.
Because that is an implementation detail. That the one uses the other 
makes it convenient for them to be the same, but the one does not _need_ 
to use the other. But in this case I think it makes sense for both to 
change. If changing findChildren is regarded as too risky though, I 
don't think that that is an argument to not change connectSlotsByName 

>>  Other possibilities may include:
>>   - Connect signals of both objects.  (Probably not a good idea since 
>>it does
>>  make it even more confusing)
>Agreed that this is not a good idea. Let's discard it.
>>   - Throw a warning if there are two objects with the same name.
>This is orthogonal.
I'd like to add a new alternative (though it does not exclude a change 
now either):

- Deprecate the behaviour and remove in Qt 6.

I have never thought this feature to lead to good design. It makes for 
"magic" in the sense that it is tricky to trace what happened. It leads 
to un-Qt-ish naming of methods, and it leads to naming methods based on 
when they are triggered instead of what they do. I find the latter 
usually leads to more readable code, more so if there is more than one 
way to trigger the behaviour encoded in the method. Last, I think 
private slots (for which this would be most used) are largely on the way 
out anyway. Trivial slots can be replaced by lambda's and non-trivial 
ones need a good function name anyway.



More information about the Development mailing list