[Development] Proposal to change connectSlotsByName behavior

Olivier Goffart olivier at woboq.com
Fri Dec 4 00:27:09 CET 2015

On Friday 4. December 2015 00:05:19 Benjamin TERRIER wrote:
> Hi everyone,
> This message follows an exchange I've had with Thiago on a bug report:
>     https://bugreports.qt.io/browse/QTBUG-49749
> In the current state, QMetaObject::connectSlotsByName() tries to find,
> for each slot named "on_<anObjectName>_<aSignalName>" in a given
> object,
> a child object named <anObjectName>" and connect the signal to the
> slot. Moreover the documentation says that the search is recursive so
> any
> descendant QObject is looked up (not only direct children).
> My issue here is that the search is done by instantiation order
> (depth-first search) which means that if 2 (or more) children have the
> same name one has
> to know which one is instantiated first to know which one will be
> connected. And of course imposing on the developer to use unique names
> throughout
> a QObject hierarchy is not feasible in particular if he/she is using a
> third-party library and might not know the object names used
> internally.
> This can lead to various hazardous situation, for instance, in a
> perfectly working software, one can break the behavior of the main
> window by simply adding
> a widget in a grand-grand-child widget.
> Or worse if the UI is made using Qt Designer, the behavior of the
> application can be changed by simply reordering the widgets in the
> layout as it will also
> change their creation order.
> An application could even break at runtime if a user enables a plugin
> or set an HMI element visible.
> In my opinion it also breaks encapsulation as the naming in a widget
> can alter the signal/slot connections in another widget.
> My proposal is to change the behavior of connectSlotsByName to do a
> breadth-first search. In this case, if a direct child is a match it
> will be used
> for the connection regardless of possible matches deeper in the
> hierarchy. Doing so would solve the situations stated above and
> restore encapsulation.
> It seems that Thiago's opinion is that it can not be changed as this
> behavior has been here since Qt 4 and it might break existing
> applications.
> On my side I think it's at least a buggy and error prone behavior or
> even a flawed design and that it must be changed as soon as possible.
> About the risk of breaking existing applications,
> I think making the change is less risky for Qt users as in the current
> state every Qt software can break with any change to an object name or
> instantiation order.
> Also as Qt Designer does push the users to use the connectSlotsByName
> mechanism, it is even possible to generate an example of this
> "unwanted" behavior
> without writing a single line of code (see attached zip in the bug report).

I tend to agree with your proposal.
I don't think it will break too many applications because anyone who was 
relying on the order of instentiation for that has just its application 
working out of pure luck. (And i'm pretty sure that your proposal is always 
the intended behaviour)

Other possibilities may include:
 - Connect signals of both objects.  (Probably not a good idea since it does 
make it even more confusing)
 - Throw a warning if there are two objects with the same name.


Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

More information about the Development mailing list