Re: [PATCH] phonesim: fix exporting of child widgets to javascript engine

[Herman van Hazendonk <github.com@herrie.org>]

Hi Andres,

On Mon, 29 Dec 2025 03:10:53 -0500, Andres Salomon wrote:
> Using the example sms.js script in doc/scriptable.txt, the following
> error occurs with phonesim built using Qt5.15:
>
> Error org.ofono.phonesim.Error.ScriptExecError: /tmp/sms.js, line 1, TypeError: Cannot read property 'leMessageSender' of undefined

We hit the same thing in LuneOS and carry a fix of our own, so I gave
yours a run.  On current master with Qt 5.15, the call.js and sms.js
examples from doc/scriptable.txt fail exactly as you describe.  With
your patch both work: call.js produces +CRING/+CLIP for 12345 on the
AT side, sms.js a +CMTI, and a script reading
tabCall.gbIncomingCall.leCaller.text gets the number back.

> I'm not sure if this is related to behavior changes in current versions
> of QJSEngine/UIC or what

It goes back to 04e66fd ("Replace QtScript with QtQml").  QtScript made
every named child of an exported QObject a property of it; QJSEngine
only exposes properties, slots and invokables, so the scripts lost
their path to the widgets with that commit.

> +    QList<QWidget*> kids = parentW->findChildren<QWidget*>(QString(),
> +            Qt::FindDirectChildrenOnly);
> +    foreach (QWidget *w, kids) {

One request: could this be a range-based for?  phonesim was ported
away from Q_FOREACH in a2bb630, and builds that define QT_NO_FOREACH
(our CMake/Qt 6 build does) fail here with "expected primary-expression
before '*' token".  Something like

	const QList<QWidget *> kids = parentW->findChildren<QWidget *>(
			QString(), Qt::FindDirectChildrenOnly);
	for (QWidget *w : kids) {

builds cleanly with Qt 6 for armv7, aarch64 and x86-64 here.

Two smaller things you may or may not want to pick up; ours does both:

 - widgets without an objectName (and Qt's own qt_* children, such as
   the viewport of a QTextEdit) still get exported, as a property with
   an empty or internal name;

 - a child whose name matches a real property of its parent would
   replace that property.  Nothing in controlbase.ui collides today,
   so this is only defensive.

Thanks for chasing this.

Herman

(The testing and this review were done with the help of Claude, an AI
assistant.)