[qutebrowser] Multi web engine support in the future
Florian Bruhin
me at the-compiler.org
Wed Mar 6 13:25:46 CET 2019
Hi,
On Tue, Mar 05, 2019 at 10:58:46PM -0300, Javier Ayres wrote:
> With the ongoing work happening as part of the research project and
> the idea of dropping support for QtWebKit, I'm wondering what is the
> plan for the future of qutebrowser regarding the support of multiple
> web engines. Are you planning to make qutebrowser a
> QtWebEngine-exclusive browser or are you going to maintain/improve the
> existing abstraction layer that exists between qutebrowser and the
> engine? Any thoughts on adding support for another specific web
> engine?
I don't really have a definitive answer on this. I do want to simplify
things where possible - in places where such a change would increase
maintainability and reduce complexity, I will (over time) merge
"abstract" code with QtWebEngine-specific code, or be less strict about
introducing QtWebEngine-specific things.
As long as there isn't another possible backend on the horizon, I think
that's the right thing to do - if there's ever another backend
introduced, the abstractions used for QtWebKit/QtWebEngine might need
some larger adjustments anyways.
In short, there's no point in things being more complex than they have
to be, and I do think complexity/maintainability is a rather big issue
at the moment. I'd rather have things a bit simpler, and removing
QtWebKit support will be a big step in that direction (moving things
from the core to extensions is another big one).
As for specific web engines: There are only three active engines I can
think of:
- WebKitGTK - obviously not integrated with Qt. QtWebKit tries to do
so, but I don't see that going anywhere in the future. Some company
with enough resources would need to pick it up, and seeing that hasn't
happened since Qt removed it three years ago, I doubt it ever will.
- Chromium embedded framework (CEF) [1][2] - has Python bindings[3] with
Qt integration[4], so the only one which would be reasonably possible
to integrate with qutebrowser. However, I don't see much benefit over
QtWebEngine, seeing that both are based on Chromium, and I'm not aware
of any killer features (like Chromium extension support) which would
be a good reason to look into it.
- Servo[5] - support for it would be amazing (and it'd be a real
alternative to QtWebEngine), but the whole ecosystem isn't there yet.
Embedding it into an existing project isn't really supported well
(though there's some community effort like [6] and [7]). Also,
someone would need to write Rust <-> Python bindings for it, and find
out how to integrate those into Qt. That someone hasn't appeared so
far, and it likely won't be me. ;-)
[1] https://bitbucket.org/chromiumembedded/cef
[2] https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
[3] https://github.com/cztomczak/cefpython
[4] https://github.com/cztomczak/cefpython/blob/master/examples/qt.py
[5] https://github.com/servo/servo
[6] https://github.com/paulrouget/servo-embedding-example
[7] https://github.com/paulrouget/servo-embedding-api
On Tue, Mar 05, 2019 at 06:41:41PM -0800, Jay Kamat wrote:
>
> Javier Ayres writes:
>
> > With the ongoing work happening as part of the research project and
> > the idea of dropping support for QtWebKit, I'm wondering what is the
> > plan for the future of qutebrowser regarding the support of multiple
> > web engines.
>
> Most likely, the abstract base classes will continue to exist even if one
> engine's support is dropped, but there will be less incentive to maintain
> them. It would probably be more effort to merge everything back together (with
> little gain). I also think that the maintenance burden of QtWebKit is not that
> high.
I agree it's not a high burden, but there are a lot of smaller things:
- It *is* additional work for major features or refactorings. The last
things I remember were Greasemonkey support (though some of that was
also needed for QtWebEngine with Qt 5.7, but support for that is going
away as well), and my PDF.js rewrite.
- It does introduce a lot of additional complexity. Both in code which
is lying around but rarely used/tested (like file listing support for
QtWebKit, or mthml downloads, or many other things QtWebEngine does
natively), and in complexity. I do like some of those abstractions
(the tab API proved to be a great idea, for example), but in other
places, I really don't like how complex and entangled things have
gotten.
- It does introduce an additional burden for any changes, because you'll
need to test on QtWebKit as well (and/or maintain the CI
infrastructure to do so), and it is often additional work for
contributors.
> In many cases, I found bugs in patches I submitted by running them
> against QtWebKit (that affected QtWebEngine in subtler ways) and vice versa,
> so to me, even if no one uses QtWebKit it remains useful.
Do you have examples for that?
> > Are you planning to make qutebrowser a QtWebEngine-exclusive browser or are
> > you going to maintain/improve the existing abstraction layer that exists
> > between qutebrowser and the engine? Any thoughts on adding support for
> > another specific web engine?
>
> The multiple backend approach works because there are multiple backends
> supported through similar (and in some cases, the same) PyQt5/Qt apis. Adding
> support for another engine would be pretty difficult as you would need to
> integrate it into both qt (and PyQt5).
>
> I think it would be extremely difficult to add support for a renderer not
> integrated into qt, as qutebrowser is heavily dependent on qt for many things.
If you check the CEF example[4] it's actually not that bad - in brief:
- Integrate the renderer's main loop with Qt (or configure it to run it
its own thread, like I think done there).
- Get the renderer to render into your window, by giving it a low-level
window handle like in that example, or by providing it with an OpenGL
thingy (surface?) to render on (which is what QtWebEngine does with
Chromium, I think).
- Dispatch some events like the window being moved/resized to the
renderer.
- Depending how things are implemented, dispatch input events as well,
if Qt is getting them instead of the renderer (doesn't seem to be
necessary in the CEF example).
> It would probably be easier to just update QtWebKit to use a newer version of
> WebKit.
I doubt it. Doing that is not something a single developer is able to
do, as we saw with QtWebKit. Annulen isn't the only one who seems to
have given up either: https://github.com/annulen/webkit/issues/775
Like said above, I don't have any hopes of it happening without a
company picking it up (which doesn't seem to be happening either).
Phew, that was a long mail, without a clear answer. :-)
Florian
--
https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
I love long mails! | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20190306/5d519f78/attachment.asc>
More information about the qutebrowser
mailing list