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