09.07.2020, 20:29, "René J.V. Bertin" <rjvber...@gmail.com>: > On Thursday July 09 2020 15:49:52 Konstantin Tokarev wrote: > >>> I don't see the problem here, as long as we're talking about actual >>> individual processes? >> >> Individual process which are in fact just different entry points of the same >> shared library. Building same files twice for Qt4 and Qt5 in the same build >> system will likely turn into maintenance nightmare, not to mention >> maintaining ifdefed code paths so that code could actually compile and work >> in both cases. > > Oh, that. Yeah, maintaining such a glue library as part of Qt[5]WebKit would > be problematic, esp. if you want to be able to build it as part of an > all-inclusive build. I wasn't thinking along those lines but rather of a > separate project, something that would build against an installed QtWebKit or > that reimplements just enough of the necessary APIs.
If such glue library is not a part of QtWebKit, it would have to deal with having Qt4 and Qt5 in the same process. That would be no easier than wrapping any other unmodified Qt5 module for use in Qt4 application. > I got the impression that the QWebView interface wasn't too extensive, > literally a window on a very complex system behind the scenes with only a > relatively small set of controls (many of which might not be necessary if you > aren't writing a full-fledged browser). I haven't yet figured out how this > would be different for the multi-process version (in fact, I haven't yet > figured out at all how you obtain it, not from looking through the Otter > Browser code in any case). Otter Browser doesn't use multiprocess mode, as it operates via QWebView API. Changing it to use multiprocess API requires writing a lot of new code (and also improvements on QtWebKit side to provide feature parity) > > R -- Regards, Konstantin _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
