Future of KParts::SelectorInterface

[Stefano Crocco]

Hello to everyone,
working on fixing the Akgregator plugin for Konqueror, I realized that 
WebEnginePart didn't correctly implement the KParts::SelectorInterface API (it 
behaved as if no element was found). Unfortunately, that API is synchronous, 
while QtWebEngine only allows to run javascript code (needed to access the 
page content) asynchronously.

I tried to make the javascript calls synchronous by using an event loop, but 
it didn't work. In the end, I decided to create a new interface, which 
provides an API closely following that of KParts::SelectorInterface but which 
is asynchronous and to have the plugin support both interfaces (see MR 
https://invent.kde.org/network/konqueror/-/merge_requests/189).

According to LXR (https://lxr.kde.org/ident?v=kf5-qt5&_i=SelectorInterface), 
currently the only parts implementing KParts::SelectorInterface are KHTML and 
KWebKitPart, which, if I'm not mistaken, are both being removed in KF6, and 
WebEnginePart which, as I said, doesn't really implement it. This means that 
in KF6 there'll be no part actually implementing this interface.

In my opinion, it would be a good idea to merge the asynchronous API I created 
in the KParts::SelectorInterface, keeping the original one in case either 
someone finds out how to implement it in WebEnginePart or another part to 
display HTML pages is created and it can implement the synchronous API.

What do you think?

Stefano