[Development] QWebEnginePage and Qt 6: protected virtual functions and signals

[Benjamin TERRIER]

On Thu, 27 May 2021 at 14:52, Allan Sandfeld Jensen <kde at carewolf.com>
wrote:

>
> Most of the changes to signal form are not that simple, and requires a lot
> more work. Not even sure we will manage to deal with the mess that is
> acceptNavigationRequest before feature freeze.


It's easy, if you force users to use direct signal/slot connections and the
handling to be done in the slot.
I thought that was the case for some existing signals.
Do you intend to support async handling for the new signals ?

Note that I am not saying the new extendable classes should not be added.
IMHO they should even be added to the old virtual protected functions.
If these classes allow async handling (like QWebEngineCertificateError
already does), it will be easy for users to add the signals if they need to.

Anyway, my point is that signals are not equivalent to virtual protected
functions.
There is a semantic difference and an architectural difference.
Just because you can turn virtual protected functions into signals does not
mean you should.
To me it is even worse than breaking ABI or source compatibility. You are
breaking the architecture of user software.

If the event looks like an internal behavior it should be a virtual
protected function.
If the event looks like something you want to tell the world about it, it
should be a signal.
Nice examples of that are all the QWidgets where "internal events" are
implemented using QEvent
and protected virtual functions, while "external events" are using signals.

Back to QWebEnginePage. IMHO handling of SSL errors or navigation requests
looks a lot like
internal events you want to implement using virtual protected functions.
For handling requests to open a new window, this can be discussed as a page
might not be best placed to know how to open a new window/tab.
Yet I still have an issue with using signals which are a many-to-many event
system to dispatch requests that must be handled only once.

Also the virtual protected functions can decide to handle the request
themselves, or fallback to their parent implementation.
That's something hardly doable with signals. Hence why replacing one by the
other can break users software architecture.

Random thoughts: Could this willingness to replace virtual
protected functions by signals be linked to QML?
In QML we do not have virtual protected functions and can only use
signals...

Regards

Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210528/31a13b02/attachment-0001.html>