@Christian-Ehrlicher said in Widget from scratch using pImpl, how to Q_PRIVATE_SLOT?:

As I said the pmf syntax needs a QObject as sender and receiver.

Ah sorry, while I was editing my example code I missed your reply :)

Oh wow didn't know that :0
So the ( SIGNAL(), SLOT() ) connection stuff is not 100% identical in terms of use-case and compatibility with the Functor-based connections?
Good to know.

@Christian-Ehrlicher said in Widget from scratch using pImpl, how to Q_PRIVATE_SLOT?:

Maybe you can also take a look on QObjectPrivate::connect() in qobject_p.h (when someone asks - I don't know this function... 🙂)

Yeah, I checked the Qt Private sources here and there while I was building my widget to see how it's done. Haven't seen this exact part, but will visit it again ;-)
Since I don't want to include the Qt Private source completely (which would make my widget highly dependent on a single Qt version), I made my own WidgetPrivate based on QWidgetPrivate "style" but without inheriting it... so no QObjectData, QObjectPrivate and whatnot... for me ;-)

Edit:

@Christian-Ehrlicher said in Widget from scratch using pImpl, how to Q_PRIVATE_SLOT?:

Maybe you can also take a look on QObjectPrivate::connect() in qobject_p.h (when someone asks - I don't know this function... 🙂)

This function?
What is there to see? Other than QObjectPrivate::connect.
You mean the use of two QObject Functors?

when someone asks - I don't know this function

Nobody will know 🤐

One way is to derive the private class from QObject or use a lambda.

If one way to make it work is using the SIGNAL / SLOT keywords again, I will probably try it.
Tried lambda, did not work either :/ Or maybe I was doing something wrong.

Edit_II:

I made my actual code work, using String-based connections while I moved the connect statement to the WidgetPrivate::init() function and hid the QTimer also behind the WidgetPrivate data.
Not 100% pleased, tho :D
Is it a good idea to make the Impl class a QObject?!
What's your recommendation?

@SGaist oh lol even missed your comment too :D Was about to add the code anyway :)

@Christian-Ehrlicher
I have used the -appstore-compliant option on the final .app made with Xcode. I used nm on the .app after using macdeployqt and it still showed the presence of the two APIs within it.

I think I will have to make my own custom Qt using the appstore-compliant feature.

Surely you mean I have to compile Qt with the "appstore-compliant" feature turned ON?

I know it is supposed to be turned ON by default for Qt downloaded through the maintenancetool. Maybe the Qt 6.4.2 that's available through the maintenance tool wasn't built with the appstore-compliant feature turned ON?

If doStuff() is not const, then don't declare d pointer as const:

Q_D(myClass) // NO "const" here! d->doStuff();

Hopefully, once this ticket is closed, everything should be easier using CMake