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

[Allan Sandfeld Jensen]

On Donnerstag, 27. Mai 2021 14:41:54 CEST you wrote:
> On Thu, 27 May 2021 at 14:17, Allan Sandfeld Jensen <kde at carewolf.com>
> 
> But it does not change my point about signal vs protected functions.
> Let's say I have a QWebEnginePage subclass that only allows some SSL errors
> by checking asynchronously a blocked list (using the defer() function of
> the QWebEngineCertificateError)
> External code can connect to the signal and ignore/block the error before
> the async check has completed, breaking the behavior of the subclass.
> 
> IMHO using signals to implement the class behavior breaks encapsulation.
> The behavior that was protected and defined in the class, is now defined
> outside of the class and is publicly available to be overridden.
> Signals are not a replacement for virtual protected functions.
> 
> I have a strong feeling that moving signals, without having the ability to
> block signals by implementing protected functions, will lead to brittle
> code for Qt users.
> The worse part, is that right now it is possible in user code to
> implement a SignalWebEnginePage, that will expose its protected functions
> as signals.
> After moving to signals, it won't be possible to not expose them. With this
> change, as-is, Qt users are losing features, for some convenience that they
> could implement themselves with a few lines of code.

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. The rework of createWindow for 
instance meant using a new class (or reusing it from the qml api), but also 
exposes way more information for the developer and could be expanded with more 
information at a later stage without breaking ABI of QWebEnginePage. See 
https://codereview.qt-project.org/c/qt/qtwebengine/+/346723

It was pretty much only certificate-error that was so simple as just calling 
either a signal or virtual method. And the only reason the derived method was 
removed was because a previous refactoring had already changed its signature 
making it less useful for source compatibility. We could easily keep the 
derived method, it just seemed redundant, and the ideal name for both clashed, 
meaning one would have to have an odd name. See first version of https://
codereview.qt-project.org/c/qt/qtwebengine/+/346682/1

Best regards
Allan