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 | [email protected] (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
signature.asc
Description: PGP signature
