[Development] Proposal to change connectSlotsByName behavior

Ziller Eike Eike.Ziller at theqtcompany.com
Fri Dec 4 08:57:10 CET 2015


> On Dec 4, 2015, at 00:05, Benjamin TERRIER <b.terrier at gmail.com> 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.

That is inherent to the “feature”, independent of how the search order is.

> 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.

Even though your suggestion would make the issue less prominent, it would not actually solve it.
It still highly depends on how the different UI parts are combined. UI from e.g. a plugin does not necessarily end up further down in the hierarchy than the widget that you wanted to connect to originally.

main
- group box
- - some other widget that is used for grouping
- - - some button (a) that you want to connect to
- plugin specific widget
- - some button with same object name as (a)

Aside from not being able to guard against things like myWidget->setParent(window()) anyhow.

IMO:
1. connectSlotsByName is a misfeature. Try not to use it at all.
2. If you really must use it (for what?), use _unique_ object names. E.g. by pre- or appending a random sequence of characters, or by using long object names that describe where they are used (choosePathForSpecificSettingInMainApplicationButton).
3. I don’t see why the risk of breaking existing applications would be worth it for a behavior change that does not really fix the issue. Even with your proposed change you must do (1) or (2), but then you don’t need the proposed change.

Br, Eike

> 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).
> 
> 
> Regards,
> 
> Benjamin
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



More information about the Development mailing list