[qutebrowser] Multi web engine support in the future

[Florian Bruhin]

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>