5 ms·

I wonder: - I read many complaints about QtWebEngine. Is there still no good alternative to this? In general, when you want to embed a browser in some GUI app.

I wonder: - I read many complaints about QtWebEngine. Is there still no good alternative to this? In general, when you want to embed a browser in some GUI app. There have been lots of attempts to solve this in the past. But it seems like this is not really solved. And making this cross platform makes it more difficult, obviously. I thought now that we have Electron, this should maybe be easier? (I remember, on Windows, it was quite easy to embed an IE browser component in your app, even in the 90s. And this worked well. Only problem was that it was IE, and Windows-only.) - You could go the other way around, and write an extension for an existing browser (Chrome, Firefox). There are also already a couple of such extensions which have similar goals as this project (keyboard-focused, minimal GUI). Why is this also suboptimal, or why does this not work as well? Why is the approach by qutebrowser better? (Some comments here seem to suggest that.) Both approaches seem suboptimal somehow.

lufte 6y ago
- I guess it depends on your environment. I run qutebrowser in Debian testing and I have no issues with QtWebEngine. What specific issues have you had? - I've tried these but they fall short most of the time. The JavaScript of the website interferes with the extension trying to grab key presses, the UI of the browser is not navigable with the keyboard or it uses its own shortcuts, and webextensions being restricted on some special pages (like about:config). The keyboard mode really needs to be a first-class citizen in my opinion.
alexfrydl 6y ago
There's webview (https://github.com/webview/webview https://github.com/webview/webview) which has bindings for many different languages, but it's a whole window rather than a UI component you can embed. It's intended to be a lightweight alternative to Electron.
The-Compiler 6y ago
I agree, all approaches to this have some kind of major drawback. The main pain point with the approach chosen by qutebrowser is probably missing support for WebExtensions (i.e. Chrome/Firefox extensions), though I still hope that'll change with QtWebEngine some day: https://bugreports.qt.io/browse/QTBUG-61676 https://bugreports.qt.io/browse/QTBUG-61676 Other similar projects are using WebKitGTK, or indeed Electron: https://vieb.dev/ https://vieb.dev/ - again, probably not better/worse than QtWebEngine, just a different set of problems. qutebrowser actually has an abstraction layer over the backend (which is why it can support QtWebEngine and the older/outdated QtWebKit, with little effort needed to keep support for the latter). If there is some new kind of library appearing some day which can draw to a Qt window and used from Python, it'd totally be possible to add support for it to qutebrowser without too much effort. I had hoped for Servo to fill that gap at some point, but so far that hasn't happened yet: https://github.com/servo/servo/issues/27579 https://github.com/servo/servo/issues/27579 Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64 https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64 As for extensions - other replies to your comment already mention this, but the main problem is that the WebExtension API is very constrained. On top of that, there's no API for handling keyboard input, so those extensions work by injecting JavaScript code handling keyboard inputs into every page you visit. That works, but only barely - lots of hacks are required for those kind of WebExtension limitations, and they won't work on pages where Mozilla decides extensions can't inject JS (such as internal pages or the Mozilla addons page). Again the folks behind Tridactyl have some ideas on how to improve the situation, but so far this hasn't happened yet: https://tridactyl.xyz/ideas/#write-a-keyboard-api-for-firefox https://tridactyl.xyz/ideas/#write-a-keyboard-api-for-firefo...
- albertzeyer 6y ago
  Thanks for the detailed answer. Many years ago, I considered adding an embedded browser (or just HTML renderer) into a game, as a simple way to build the game menu. The requirements mostly were: - We needed the raw pixels as output. This was SDL, and the game was purely pixel based. Should also support alpha channel / transparency if possible. Also we would need to be in full control of all input events (keyboard inputs, mouse clicks), and have some easy way to handle some events like button clicks etc. - Cross-platform (at least Windows, Linux, Mac, iOS, Android, and potentially more). Should also be easy to build, and not have much dependencies. - It should be a small dependency (WebKit was way overkill; or maybe you can build a stripped down version?). We gave up. Although we didn't really needed all the modern HTML features, and also no JS. I guess for a projects like yours, you have somewhat different requirements. I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream. I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now. https://github.com/albertz/Pyjector https://github.com/albertz/Pyjector https://github.com/albertz/chromehacking/blob/master/chromehacking.py https://github.com/albertz/chromehacking/blob/master/chromeh... https://src.chromium.org/viewvc/chrome/branches/874/src/chrome/common/mac/cfbundle_blocker.mm?pathrev=105568 https://src.chromium.org/viewvc/chrome/branches/874/src/chro...
  - The-Compiler 6y ago
    I've recently learned about litehtml, which seems pretty much what you are describing: http://www.litehtml.com/ http://www.litehtml.com/ Looks like it started in 2012, but I've never heard about it until a recent plan from Qt to write a wrapper around it: https://lists.qt-project.org/pipermail/development/2021-January/040915.html https://lists.qt-project.org/pipermail/development/2021-Janu... (Probably so that simple things like their help viewer don't need a rather heavy QtWebEngine)
  - The-Compiler 6y ago
    Whoops, I forgot about the other things I wanted to reply to :) > I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream. Yeah. People have suggested that in the past, but keeping up with e.g. Chromium is insane. When QtWebEngine updates their Chromium snapshot (a subset of the entire source) all couple of months, we're talking about millions of changed lines, and I've heard they need around a person-month every time to adjust their stable API to that. Also see: - https://chromium.googlesource.com/chromium/src.git/+log https://chromium.googlesource.com/chromium/src.git/+log - https://twitter.com/the_compiler/status/1330896103911264257 https://twitter.com/the_compiler/status/1330896103911264257 It's pretty much a commit all couple of minutes, almost around the clock. > I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now. I was actually wondering what someone could do via ChromeDriver: https://chromedriver.chromium.org/ https://chromedriver.chromium.org/ But I suppose the kind of UI/UX you could build with that would still be quite limited, perhaps even more so than what WebExtensions like Vimium or Tridactyl can do.
Timothee 6y ago
> Why is this also suboptimal, or why does this not work as well? Why is the approach by qutebrowser better? Building a browser extension will always have limitations. For example, if you download a file, you usually don't have a way to open/delete/retry it through a keyboard command or an extension. Or moving tabs around between windows, change the order in the current window. You have to go back to using the mouse for many tasks, even with extensions. Browsers also have a lot of minimal chrome UI which you can't get rid of with an extension. (a while ago, I did use Safari in a mode where it only had the very thin top bar, but it wasn't super practical sometimes because it was not the intended use-case) Having qutebrowser built with the vim-like mode as first-class citizen gives more control over what can be done and how it looks. I've been using it for a few years now and love the keyboard-shortcut centric aspect (I also use Vim) and the minimalism and customizability of the UI.

lufte 6y ago

- I guess it depends on your environment. I run qutebrowser in Debian testing and I have no issues with QtWebEngine. What specific issues have you had? - I've tried these but they fall short most of the time. The JavaScript of the website interferes with the extension trying to grab key presses, the UI of the browser is not navigable with the keyboard or it uses its own shortcuts, and webextensions being restricted on some special pages (like about:config). The keyboard mode really needs to be a first-class citizen in my opinion.

alexfrydl 6y ago

There's webview (https://github.com/webview/webview https://github.com/webview/webview) which has bindings for many different languages, but it's a whole window rather than a UI component you can embed. It's intended to be a lightweight alternative to Electron.

The-Compiler 6y ago

I agree, all approaches to this have some kind of major drawback. The main pain point with the approach chosen by qutebrowser is probably missing support for WebExtensions (i.e. Chrome/Firefox extensions), though I still hope that'll change with QtWebEngine some day: https://bugreports.qt.io/browse/QTBUG-61676 https://bugreports.qt.io/browse/QTBUG-61676 Other similar projects are using WebKitGTK, or indeed Electron: https://vieb.dev/ https://vieb.dev/ - again, probably not better/worse than QtWebEngine, just a different set of problems. qutebrowser actually has an abstraction layer over the backend (which is why it can support QtWebEngine and the older/outdated QtWebKit, with little effort needed to keep support for the latter). If there is some new kind of library appearing some day which can draw to a Qt window and used from Python, it'd totally be possible to add support for it to qutebrowser without too much effort. I had hoped for Servo to fill that gap at some point, but so far that hasn't happened yet: https://github.com/servo/servo/issues/27579 https://github.com/servo/servo/issues/27579 Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64 https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64 As for extensions - other replies to your comment already mention this, but the main problem is that the WebExtension API is very constrained. On top of that, there's no API for handling keyboard input, so those extensions work by injecting JavaScript code handling keyboard inputs into every page you visit. That works, but only barely - lots of hacks are required for those kind of WebExtension limitations, and they won't work on pages where Mozilla decides extensions can't inject JS (such as internal pages or the Mozilla addons page). Again the folks behind Tridactyl have some ideas on how to improve the situation, but so far this hasn't happened yet: https://tridactyl.xyz/ideas/#write-a-keyboard-api-for-firefox https://tridactyl.xyz/ideas/#write-a-keyboard-api-for-firefo...

albertzeyer 6y ago
Thanks for the detailed answer. Many years ago, I considered adding an embedded browser (or just HTML renderer) into a game, as a simple way to build the game menu. The requirements mostly were: - We needed the raw pixels as output. This was SDL, and the game was purely pixel based. Should also support alpha channel / transparency if possible. Also we would need to be in full control of all input events (keyboard inputs, mouse clicks), and have some easy way to handle some events like button clicks etc. - Cross-platform (at least Windows, Linux, Mac, iOS, Android, and potentially more). Should also be easy to build, and not have much dependencies. - It should be a small dependency (WebKit was way overkill; or maybe you can build a stripped down version?). We gave up. Although we didn't really needed all the modern HTML features, and also no JS. I guess for a projects like yours, you have somewhat different requirements. I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream. I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now. https://github.com/albertz/Pyjector https://github.com/albertz/Pyjector https://github.com/albertz/chromehacking/blob/master/chromehacking.py https://github.com/albertz/chromehacking/blob/master/chromeh... https://src.chromium.org/viewvc/chrome/branches/874/src/chrome/common/mac/cfbundle_blocker.mm?pathrev=105568 https://src.chromium.org/viewvc/chrome/branches/874/src/chro...
- The-Compiler 6y ago
  I've recently learned about litehtml, which seems pretty much what you are describing: http://www.litehtml.com/ http://www.litehtml.com/ Looks like it started in 2012, but I've never heard about it until a recent plan from Qt to write a wrapper around it: https://lists.qt-project.org/pipermail/development/2021-January/040915.html https://lists.qt-project.org/pipermail/development/2021-Janu... (Probably so that simple things like their help viewer don't need a rather heavy QtWebEngine)
- The-Compiler 6y ago
  Whoops, I forgot about the other things I wanted to reply to :) > I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream. Yeah. People have suggested that in the past, but keeping up with e.g. Chromium is insane. When QtWebEngine updates their Chromium snapshot (a subset of the entire source) all couple of months, we're talking about millions of changed lines, and I've heard they need around a person-month every time to adjust their stable API to that. Also see: - https://chromium.googlesource.com/chromium/src.git/+log https://chromium.googlesource.com/chromium/src.git/+log - https://twitter.com/the_compiler/status/1330896103911264257 https://twitter.com/the_compiler/status/1330896103911264257 It's pretty much a commit all couple of minutes, almost around the clock. > I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now. I was actually wondering what someone could do via ChromeDriver: https://chromedriver.chromium.org/ https://chromedriver.chromium.org/ But I suppose the kind of UI/UX you could build with that would still be quite limited, perhaps even more so than what WebExtensions like Vimium or Tridactyl can do.

Timothee 6y ago

> Why is this also suboptimal, or why does this not work as well? Why is the approach by qutebrowser better? Building a browser extension will always have limitations. For example, if you download a file, you usually don't have a way to open/delete/retry it through a keyboard command or an extension. Or moving tabs around between windows, change the order in the current window. You have to go back to using the mouse for many tasks, even with extensions. Browsers also have a lot of minimal chrome UI which you can't get rid of with an extension. (a while ago, I did use Safari in a mode where it only had the very thin top bar, but it wasn't super practical sometimes because it was not the intended use-case) Having qutebrowser built with the vim-like mode as first-class citizen gives more control over what can be done and how it looks. I've been using it for a few years now and love the keyboard-shortcut centric aspect (I also use Vim) and the minimalism and customizability of the UI.