[qutebrowser] Multi web engine support in the future

[Jay Kamat]

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. 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.

> 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.
It would probably be easier to just update QtWebKit to use a newer version of
WebKit.

-Jay