Qutebrowser 2.0(lists.schokokeks.org)
lists.schokokeks.org
Qutebrowser 2.0
https://lists.schokokeks.org/pipermail/qutebrowser-announce/2021-January/000090.html
128 comments
Wow, you're not kidding. Been aware of it for years and just trying it for the first time in ages now after a long time on Firefox with Tridactyl.
Zero configuration or reading docs and most of the default keybindings just stick. It's smooth and minimal and so far things render great.
Visual/caret mode seems a bit wonky with input elements but I may just have to read up on it a bit.
Zero configuration or reading docs and most of the default keybindings just stick. It's smooth and minimal and so far things render great.
Visual/caret mode seems a bit wonky with input elements but I may just have to read up on it a bit.
> Zero configuration or reading docs and most of the default keybindings just stick. It's smooth and minimal and so far things render great.
Yay! Discoverability and being intuitive are indeed things I try to keep focusing on - if you have any suggestions I'm all ears!
> Visual/caret mode seems a bit wonky with input elements but I may just have to read up on it a bit.
It's based on Chromium's caret mode code (in JS): https://chrome.google.com/webstore/detail/caret-browsing/fkl...
I think a better alternative for input elements would be to have vim emulation instead: https://github.com/qutebrowser/qutebrowser/issues/827
Yay! Discoverability and being intuitive are indeed things I try to keep focusing on - if you have any suggestions I'm all ears!
> Visual/caret mode seems a bit wonky with input elements but I may just have to read up on it a bit.
It's based on Chromium's caret mode code (in JS): https://chrome.google.com/webstore/detail/caret-browsing/fkl...
I think a better alternative for input elements would be to have vim emulation instead: https://github.com/qutebrowser/qutebrowser/issues/827
> There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient.
I moved from linux+qutebrowser to macos+safari a couple years ago (mostly because I needed to for my work computer and was getting tired of fighting ableton+wine on my personal computer) but I really love qb (I even wrote a blog post on it: https://jamesbvaughan.com/qutebrowser). I miss a lot of things about it, with "o" being one of the big ones.
I know that I can use qutebrowser on macos, but using safari (with Vimari) just feels more integrated with the OS and my other Apple devices, and that's been something I've enjoyed more than I expected to.
Writing this is making me think I should give qb on macos another shot though...
I moved from linux+qutebrowser to macos+safari a couple years ago (mostly because I needed to for my work computer and was getting tired of fighting ableton+wine on my personal computer) but I really love qb (I even wrote a blog post on it: https://jamesbvaughan.com/qutebrowser). I miss a lot of things about it, with "o" being one of the big ones.
I know that I can use qutebrowser on macos, but using safari (with Vimari) just feels more integrated with the OS and my other Apple devices, and that's been something I've enjoyed more than I expected to.
Writing this is making me think I should give qb on macos another shot though...
> There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great.
Nailed it. I also like the fact that the search also works on bookmarks. I've the feeling that it actually helped me forget less about them.
Nailed it. I also like the fact that the search also works on bookmarks. I've the feeling that it actually helped me forget less about them.
> Love using qutebrowser. Really an amazing opensource browser! The only extension necessary for me was adblocking and now it's even better!
Yay, glad to hear that!
> I did/continue to have issues with qt-webengine though, like 144hz monitor with qt webengine is limited to 60hz but these things are unrelated to qutebrowser.
I'm assuming you're already aware of it, but for context, here's the related Qt bug: https://bugreports.qt.io/browse/QTBUG-76006
> In fact most of my "bugs" can be related to upstream qt webengine and wayland support. I feel bad for the authors of qutebrowser for so often getting issues that is actually an upstream bug in qt.
It's not that bad, qutebrowser also has more than enough bugs on its own :D
Jokes aside: If I can reproduce something myself, I'll gladly report it upstream. If possible in any way, I'll add a workaround to qutebrowser. Sometimes neither is the case, then I'll close those bugs asking the reporter to report them upstream directly.
> It doesn't help that qt webengine work is rather slow (imo)
Yeah, it is. It's a relatively small team working on QtWebEngine, and even just keeping up with Chromium changes (and backporting security fixes) is a monumental task. When they update their Chromium snapshot (a subset of the entire Chromium tree), often there are millions of changed lines, and I've heard they regularly need around a person-month or so to adjust their stable API to those changes.
Still, there are only very few alternatives to it, and there's no way qutebrowser could shoulder this kind of work directly (by e.g. being based on Chromium's source, something people did suggest in the past).
> There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great. My colleagues sometimes were amazed at how fast I could navigate across the browser all thanks to this great software
Hehe, yeah! There's a lot of logic people want to add to that (e.g. sorting by frequency weighed in rather than just recency), but all of that has the potential of making things much less snappy. I kind of like the simple approach, but I'm also open to improving it if it can yield even better matches without sacrificing performance. It's a hard balance to strike sometimes.
> Thank you qutebrowser!
You're welcome!
Yay, glad to hear that!
> I did/continue to have issues with qt-webengine though, like 144hz monitor with qt webengine is limited to 60hz but these things are unrelated to qutebrowser.
I'm assuming you're already aware of it, but for context, here's the related Qt bug: https://bugreports.qt.io/browse/QTBUG-76006
> In fact most of my "bugs" can be related to upstream qt webengine and wayland support. I feel bad for the authors of qutebrowser for so often getting issues that is actually an upstream bug in qt.
It's not that bad, qutebrowser also has more than enough bugs on its own :D
Jokes aside: If I can reproduce something myself, I'll gladly report it upstream. If possible in any way, I'll add a workaround to qutebrowser. Sometimes neither is the case, then I'll close those bugs asking the reporter to report them upstream directly.
> It doesn't help that qt webengine work is rather slow (imo)
Yeah, it is. It's a relatively small team working on QtWebEngine, and even just keeping up with Chromium changes (and backporting security fixes) is a monumental task. When they update their Chromium snapshot (a subset of the entire Chromium tree), often there are millions of changed lines, and I've heard they regularly need around a person-month or so to adjust their stable API to those changes.
Still, there are only very few alternatives to it, and there's no way qutebrowser could shoulder this kind of work directly (by e.g. being based on Chromium's source, something people did suggest in the past).
> There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great. My colleagues sometimes were amazed at how fast I could navigate across the browser all thanks to this great software
Hehe, yeah! There's a lot of logic people want to add to that (e.g. sorting by frequency weighed in rather than just recency), but all of that has the potential of making things much less snappy. I kind of like the simple approach, but I'm also open to improving it if it can yield even better matches without sacrificing performance. It's a hard balance to strike sometimes.
> Thank you qutebrowser!
You're welcome!
Ctrl + L then "*" will search in bookmarks for firefox.
Ctrl + L will focus the url bar, and then you can use several modifiers to search different things. E.G: ? will run a search engine query, even if you type something that looks like a domain name after it, such as a file anme.
Ctrl + L will focus the url bar, and then you can use several modifiers to search different things. E.G: ? will run a search engine query, even if you type something that looks like a domain name after it, such as a file anme.
https://qutebrowser.org/
> qutebrowser is a keyboard-focused browser with a minimal GUI. It’s based on Python and PyQt5 and free software, licensed under the GPL.
> It was inspired by other browsers/addons like dwb and Vimperator/Pentadactyl.
> qutebrowser is a keyboard-focused browser with a minimal GUI. It’s based on Python and PyQt5 and free software, licensed under the GPL.
> It was inspired by other browsers/addons like dwb and Vimperator/Pentadactyl.
I like the way qutebrowser works and the way it avoids wasting space, and I wish I could use it. But over several versions of Ubuntu and qutebrowser, I’ve encountered too many problems; I think most are due to the qtwebengine and the fact that qutebrowser is made with Python.
The latter often leads to the familiar dependency hell when trying to install or upgrade the program.
I have frequent crashes, it’s slow at rendering pages, it uses more memory than (for example) chromium and seems to leak memory; any kind of CSS animation causes the CPU to have a major workout. After one upgrade most video stopped working.
I never cared about the ad blocker, as I use a hosts file for that. Why doesn’t everyone? It seems to be a better solution.
The latter often leads to the familiar dependency hell when trying to install or upgrade the program.
I have frequent crashes, it’s slow at rendering pages, it uses more memory than (for example) chromium and seems to leak memory; any kind of CSS animation causes the CPU to have a major workout. After one upgrade most video stopped working.
I never cared about the ad blocker, as I use a hosts file for that. Why doesn’t everyone? It seems to be a better solution.
> The latter often leads to the familiar dependency hell when trying to install or upgrade the program.
Can you elaborate?
> I have frequent crashes, it’s slow at rendering pages, it uses more memory than (for example) chromium and seems to leak memory; any kind of CSS animation causes the CPU to have a major workout.
Those are indeed most likely caused by the underlying QtWebEngine in some way - though there also have been some performance improvements in qutebrowser itself, with some more planned: https://github.com/qutebrowser/qutebrowser/issues?q=is%3Aope...
> After one upgrade most video stopped working.
If you installed qutebrowser outside of Ubuntu's packages, that might be caused by the prebuilt Qt lacking proprietary codec support.
Despite that, it's what I'd recommend if you're on a Ubuntu LTS with often grossly outdated Qt versions: https://github.com/qutebrowser/qutebrowser/blob/master/doc/i...
> I never cared about the ad blocker, as I use a hosts file for that. Why doesn’t everyone? It seems to be a better solution.
That's essentially what qutebrowser did before this release as well - but many ads and trackers are served from the visited page directly rather than a third-party host.
Can you elaborate?
> I have frequent crashes, it’s slow at rendering pages, it uses more memory than (for example) chromium and seems to leak memory; any kind of CSS animation causes the CPU to have a major workout.
Those are indeed most likely caused by the underlying QtWebEngine in some way - though there also have been some performance improvements in qutebrowser itself, with some more planned: https://github.com/qutebrowser/qutebrowser/issues?q=is%3Aope...
> After one upgrade most video stopped working.
If you installed qutebrowser outside of Ubuntu's packages, that might be caused by the prebuilt Qt lacking proprietary codec support.
Despite that, it's what I'd recommend if you're on a Ubuntu LTS with often grossly outdated Qt versions: https://github.com/qutebrowser/qutebrowser/blob/master/doc/i...
> I never cared about the ad blocker, as I use a hosts file for that. Why doesn’t everyone? It seems to be a better solution.
That's essentially what qutebrowser did before this release as well - but many ads and trackers are served from the visited page directly rather than a third-party host.
“Can you elaborate?”
First, thanks for your work on Qutebrowser. I’m sure it’s exhausting in many ways, and I know it’s basically a hobby. So despite my complaints I’m impressed and I love the concept. And I’ve noticed you are consistently responsive to users, despite this not being a job.
Pip installing QB usually leads to errors about missing or wrong Python QT libraries, and attempts to install those lead to other errors. I don’t expect you to deal with these problems; it’s what I’ve come to expect with large Python programs. Using a virtual env. did not solve the issues for me.
EDIT: or it will install, but then when I run it, I get an error about something missing or being the wrong version.
The nonworking video, I’m sure, is due to missing codecs.
“many ads and trackers are served from the visited page directly”
True, but the hosts file seems to catch most everything.
First, thanks for your work on Qutebrowser. I’m sure it’s exhausting in many ways, and I know it’s basically a hobby. So despite my complaints I’m impressed and I love the concept. And I’ve noticed you are consistently responsive to users, despite this not being a job.
Pip installing QB usually leads to errors about missing or wrong Python QT libraries, and attempts to install those lead to other errors. I don’t expect you to deal with these problems; it’s what I’ve come to expect with large Python programs. Using a virtual env. did not solve the issues for me.
EDIT: or it will install, but then when I run it, I get an error about something missing or being the wrong version.
The nonworking video, I’m sure, is due to missing codecs.
“many ads and trackers are served from the visited page directly”
True, but the hosts file seems to catch most everything.
> despite this not being a job
Yes and no - I'm only employed for 2 days a week, and earn enough in (recurring) donation income for this to be considered a part-time job. I also do some training/consulting around Python/pytest with my company (Bruhin Software), but that's usually only a couple of days per month.
> Using a virtual env. did not solve the issues for me.
That's weird, I'm not aware of any issues like that which wouldn't be resolved by using a virtualenv. You might want to try using qutebrowser's mkvenv.py which takes care of everything (or at least tries to):
https://github.com/qutebrowser/qutebrowser/blob/master/doc/i...
Yes and no - I'm only employed for 2 days a week, and earn enough in (recurring) donation income for this to be considered a part-time job. I also do some training/consulting around Python/pytest with my company (Bruhin Software), but that's usually only a couple of days per month.
> Using a virtual env. did not solve the issues for me.
That's weird, I'm not aware of any issues like that which wouldn't be resolved by using a virtualenv. You might want to try using qutebrowser's mkvenv.py which takes care of everything (or at least tries to):
https://github.com/qutebrowser/qutebrowser/blob/master/doc/i...
“earn enough in (recurring) donation income for this to be considered a part-time job”
Glad to hear that!
“I'm not aware of any issues like that which wouldn't be resolved by using a virtualenv.”
To be more accurate, if I recall correctly, I think it did resolve the dependency issues, but the result was that the version of QB installed this way was crashy, or there was some other problem. Sorry, I didn’t take notes. I haven’t tried mkvenv.py, thanks for suggesting that.
Glad to hear that!
“I'm not aware of any issues like that which wouldn't be resolved by using a virtualenv.”
To be more accurate, if I recall correctly, I think it did resolve the dependency issues, but the result was that the version of QB installed this way was crashy, or there was some other problem. Sorry, I didn’t take notes. I haven’t tried mkvenv.py, thanks for suggesting that.
The hosts file solution doesn’t help with elements on a page (like cookie banners) which can load from allowed domains, or elements on a page such as YouTube ad-rolls.
But I agree about the memory usage, qute uses insane amounts of memory and it gets worse over time, I think this is caused primarily by memory fragmentation in python- but it’s more evident with large memory hungry programs like a browser.
https://dzone.com/articles/python-memory-issues-tips-and-tri...
But I agree about the memory usage, qute uses insane amounts of memory and it gets worse over time, I think this is caused primarily by memory fragmentation in python- but it’s more evident with large memory hungry programs like a browser.
https://dzone.com/articles/python-memory-issues-tips-and-tri...
> But I agree about the memory usage, qute uses insane amounts of memory and it gets worse over time, I think this is caused primarily by memory fragmentation in python- but it’s more evident with large memory hungry programs like a browser.
Yeah, something is leaking memory. Unfortunately, nobody has figured out what exactly yet - and everything I've seen so far is not pointing to Python (or qutebrowser) as a culprit:
https://github.com/qutebrowser/qutebrowser/issues/1476#issue...
Yeah, something is leaking memory. Unfortunately, nobody has figured out what exactly yet - and everything I've seen so far is not pointing to Python (or qutebrowser) as a culprit:
https://github.com/qutebrowser/qutebrowser/issues/1476#issue...
“The hosts file solution doesn’t help with elements on a page (like cookie banners) which can load from allowed domains, or elements on a page such as YouTube ad-rolls.”
You’re right about that.
I’m using Chromium v.87 now and it’s the first graphical browser I’ve encountered in a while that does not leak memory. It’s fast, stable, smooth, does not peg the CPU, and I don’t need to restart it periodically to reclaim RAM.
You’re right about that.
I’m using Chromium v.87 now and it’s the first graphical browser I’ve encountered in a while that does not leak memory. It’s fast, stable, smooth, does not peg the CPU, and I don’t need to restart it periodically to reclaim RAM.
How many browsers have you tried? Firefox regularly runs for a long time on my machine, and I have no issues with its memory usage.
Firefox was my main browser for a long time. But after an upgrade it starting misbehaving in some way that I don’t remember now.
It seems to be difficult to generalize about these things. Someone will say that a particular version of a browser leaks memory, or pegs the CPU, and someone else will say that the same version has no problems.
It seems to be difficult to generalize about these things. Someone will say that a particular version of a browser leaks memory, or pegs the CPU, and someone else will say that the same version has no problems.
> It seems to be difficult to generalize about these things. Someone will say that a particular version of a browser leaks memory, or pegs the CPU, and someone else will say that the same version has no problems.
FWIW that's indeed my experience with qutebrowser as well. Everyone seems to have rather different experiences (or expectations?) when it comes to performance and RAM usage. Doesn't exactly make it easier to track issues down, unfortunately.
FWIW that's indeed my experience with qutebrowser as well. Everyone seems to have rather different experiences (or expectations?) when it comes to performance and RAM usage. Doesn't exactly make it easier to track issues down, unfortunately.
Yeah, I realize just saying “it leaks memory” is useless to you in tracking down why. It could be due to any of a dozen different things that QB interacts with. And the next level of investigation is something that I don’t really have the skills, nor, probably, the time, to undertake.
I'm not blaming you for that - those things are insanely hard to track down in a complex application spanning multiple programming languages and approaches to memory management... Unfortunately I have no idea where to start either :-/
If you’re into programs with Vim-like key bindings, I can wholeheartedly recommend Qutebrowser. Back when Firefox transitioned from the old extension system and Vimperator stopped working, I started using Qutebrowser instead. I stopped due to the lack of good ad blocking, but sorely miss the key bindings every day. Will give it a new try now!
I use qutebrowser and Firefox + Vimium (as a lightweight layer of vim functionalities on top of Firefow). You may look a it but a little bit of configuration is needed to homogenize the keybindings between qutebrowser and Vimium.
> I stopped due to the lack of good ad blocking, but sorely miss the key bindings every day. Will give it a new try now!
Welcome back then! Happy about feedback if you miss something else :)
If qutebrowser isn't for you, there are also various other browser addons you might want to try:
https://github.com/qutebrowser/qutebrowser#similar-projects
Welcome back then! Happy about feedback if you miss something else :)
If qutebrowser isn't for you, there are also various other browser addons you might want to try:
https://github.com/qutebrowser/qutebrowser#similar-projects
I owe this a try as well. For me, vimperator/pentadactyl was an absolute dream. I kept them running for a long time, but eventually had to abandon them along with the old firefox versions. The WebExtension imitations don't even come close.
Donated to this project a while back, first FOSS project I donated to. Worth 10x as much. No Vim keybind extension even comes close to how well it works for me. Only downside is that sometimes I need to go to chromium/ff for websites that don't work with QB's webengine.
Thanks for the support!
As for sites not working, if there isn't an issue about them yet, please report them! Often all that's needed is either a faked user-agent or a small JavaScript snippet:
https://github.com/qutebrowser/qutebrowser/blob/v2.0.1/quteb... https://github.com/qutebrowser/qutebrowser/tree/v2.0.1/quteb...
As for sites not working, if there isn't an issue about them yet, please report them! Often all that's needed is either a faked user-agent or a small JavaScript snippet:
https://github.com/qutebrowser/qutebrowser/blob/v2.0.1/quteb... https://github.com/qutebrowser/qutebrowser/tree/v2.0.1/quteb...
Any reason my Antivirus considers it a problem?
"
C:\Program Files\qutebrowser\qutebrowser.exe is infected with Gen:Variant.Mikey.118185
"
This is with Bitdefender.
I downloaded the prebuilt windows binary from https://github.com/qutebrowser/qutebrowser/releases
I downloaded the prebuilt windows binary from https://github.com/qutebrowser/qutebrowser/releases
Some AVs have an issue with PyInstaller: https://github.com/qutebrowser/qutebrowser/issues/4269
I've also seen some AVs having an issue with QT dlls, probably because some malware used them at some point.
I've also seen some AVs having an issue with QT dlls, probably because some malware used them at some point.
Antivirus software can have random positives, and for niche software they might not correct that.
But it is a good reason to only run stuff that has a pgp-signed checksum.
But it is a good reason to only run stuff that has a pgp-signed checksum.
Like mentioned by toyg, AV engines are really overzealous when it comes to PyInstaller executables :(
Not much I can do about that, but I opened https://github.com/qutebrowser/qutebrowser/issues/6081 to send a couple of appeals whenever I'm bored enough to do so.
Not much I can do about that, but I opened https://github.com/qutebrowser/qutebrowser/issues/6081 to send a couple of appeals whenever I'm bored enough to do so.
If the Anti Virus spits out something with "Gen" or similiar in the name it's some atodetection bullshit and you should take it up with your antivirus vendor instead of botherung anyone else.
>This release integrates Brave's Rust adblocking library if the "adblock" Python library is available.
I can't parse this. It's a Rust library in a C++ browser but you need a Python library to use it?
Beyond that and given how glitchy Tridactyl is on firefox I'll be sure to check this out. I'm just a bit bummed that it's yet another chromium-based browser, but I guess there's no real viable alternative these days.
EDIT:
I can't parse this. It's a Rust library in a C++ browser but you need a Python library to use it?
Beyond that and given how glitchy Tridactyl is on firefox I'll be sure to check this out. I'm just a bit bummed that it's yet another chromium-based browser, but I guess there's no real viable alternative these days.
EDIT:
12:47:32 CRITICAL: Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile)
[1] 567012 abort (core dumped) qutebrowser
Sounds like a display driver issue. Make sure to run a system upgrade and reboot.
Some Nvidia users reported success after switching from nouveau to proprietary drivers. If you're (understandably) unwilling to change out your display drivers for a single application, you might want to try forcing software rendering in qutebrowser via the config [1]
[1]: https://github.com/qutebrowser/qutebrowser/issues/3276#issue...
Some Nvidia users reported success after switching from nouveau to proprietary drivers. If you're (understandably) unwilling to change out your display drivers for a single application, you might want to try forcing software rendering in qutebrowser via the config [1]
[1]: https://github.com/qutebrowser/qutebrowser/issues/3276#issue...
Interesting another QtWebEngine based browser also made a similar move a few months ago to provide an adblock: https://jbbgameich.github.io/misc/2020/12/21/rust-in-a-kde-p...
Oh, that was an interesting read! I wasn't aware of Angelfish or how it integrated the same library.
> qutebrowser is a keyboard-focused browser with a minimal GUI. It’s based on Python and PyQt5 and free software, licensed under the GPL.
So it's a python-based browser. If a certain python package is installed that has bindings for the (rust-based) adblock library, then it is used.
So it's a python-based browser. If a certain python package is installed that has bindings for the (rust-based) adblock library, then it is used.
It's both. PyQt are python-bindings to the Qt-code in C++. Python acts here mainly as the clue-language to connect and control the parts in C++, and other parts like this rust-based adblocker. It's a funny melting-pot...
Yup! So far, we have C (Python runtime), C++ (Qt), Python (qutebrowser itself), Rust (adblocker) and JavaScript (web stuff and some of qutebrowser's code) involved. Probably some other small things I'm not thinking of right now.
It's... challenging sometimes, but still working surprisingly well overall.
It's... challenging sometimes, but still working surprisingly well overall.
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.
- 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.
> 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.
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.
- 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.
- 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.
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
Other similar projects are using WebKitGTK, or indeed Electron: 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
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: 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-firefo...
Other similar projects are using WebKitGTK, or indeed Electron: 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
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: 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-firefo...
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/chromehacking/blob/master/chromeh... https://src.chromium.org/viewvc/chrome/branches/874/src/chro...
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/chromehacking/blob/master/chromeh... https://src.chromium.org/viewvc/chrome/branches/874/src/chro...
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://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/
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.
> 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://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/
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.
I've recently learned about litehtml, which seems pretty much what you are describing: 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-Janu...
(Probably so that simple things like their help viewer don't need a rather heavy QtWebEngine)
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-Janu...
(Probably so that simple things like their help viewer don't need a rather heavy QtWebEngine)
There's 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.
Another QtWebEngine based browser is Falkon[1], part of the KDE project. It works well for most websites which stick to standard web development practices, has built-in ad blocker and the reason to use it would be in memory constrained environments as QtWebEngine seems to be quite memory efficient.
But the development is slow, last major release was in Mar 2019.
[1]https://userbase.kde.org/Falkon
But the development is slow, last major release was in Mar 2019.
[1]https://userbase.kde.org/Falkon
> But the development is slow, last major release was in Mar 2019.
I'm afraid it seems pretty much dead at this point... Looking at https://github.com/KDE/falkon/commits/master there's only a (non-automated) commit all couple of months or so. Also see https://github.com/KDE/falkon/graphs/contributors
I'm afraid it seems pretty much dead at this point... Looking at https://github.com/KDE/falkon/commits/master there's only a (non-automated) commit all couple of months or so. Also see https://github.com/KDE/falkon/graphs/contributors
Otter Browser is more recent albeit crashier, but the resource requeriments are close.
Note that Otter Browser uses QtWebKit by default, which is based on a 2018 WebKit with many known security issues: https://github.com/qtwebkit/qtwebkit/releases
Will check it out. By 'crashier' do you mean the browser crashes or the website fails to load? If it's the former, then I don't remember Falkon ever crashing.
The browser may crash, albeit it may be due to my QT version (I use Slackware current). Falkon has been much more stable on Slackware 14.2.
I'm really a fan of keyboard driven browsing (currently sticking with chromium + vimium) so I'll give a try to qutebrowser and would be cool if not only has adblocking but uMatrix and password manager extensions so that it can become more of a daily driver while staying snappy.
There's https://gitlab.com/jgkamat/jmatrix though it's quite an unofficial hack, and I have no idea if it still works with v2.0.0.
I'd really like to integrate something uMatrix-like (with nice keyboard usage) into qutebrowser some day, but so far I didn't get around to it: https://github.com/qutebrowser/qutebrowser/issues/28
As for password managers, as someone already mentioned in another reply, there are userscripts: https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
I'd really like to integrate something uMatrix-like (with nice keyboard usage) into qutebrowser some day, but so far I didn't get around to it: https://github.com/qutebrowser/qutebrowser/issues/28
As for password managers, as someone already mentioned in another reply, there are userscripts: https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
Password managers are supported via scripting integration. GNU pass, lastpass, keepass, and bitwarden are all supported, you just need to have the respective local CLI client installed.
Qutebrowser is so awesome! Sadly, I had to switch back to Firefox and Vimium because I never figured out how to enable Kerberos. With Firefox, this easy, go to about:config and edit the negotiate auth whitelist. I tried to set all kinds of flags but gave up after a couple of days.
It might just work if you're on Qt 5.12.1 or newer: https://bugreports.qt.io/browse/QTBUG-51082
Thanks a lot for the tip! Will give it another go :-)
I'm building it now with PyQt from source on ubuntu-20.04 since PyQt5-sip is missing from OS packages. Isn't this (a 50-minute build time on a popular distro) seen as a big barrier to adoption ?
> since PyQt5-sip is missing from OS packages
Arguably this is a Ubuntu (Debian?) packaging bug. Upstream recommends using "PyQt5.sip" ever since PyQt 5.11, yet Ubuntu seems to package PyQt 5.14 but retaining the old "sip" name.
I wasn't aware of it, or I would've kept the (quite small) compatibility shim in v2.0.0 - I opened an issue here: https://github.com/qutebrowser/qutebrowser/issues/6082
In the meantime, you could probably symlink it instead:
Alternatively, either use the Ubuntu "qutebrowser" package (pre-v2.0.0), or install in a virtualenv instead:
https://github.com/qutebrowser/qutebrowser/blob/master/doc/i...
There's an option there to install a binary Qt/PyQt from PyPI, so you don't need to build anything from source. However, note that it comes without proprietary codec support.
Arguably this is a Ubuntu (Debian?) packaging bug. Upstream recommends using "PyQt5.sip" ever since PyQt 5.11, yet Ubuntu seems to package PyQt 5.14 but retaining the old "sip" name.
I wasn't aware of it, or I would've kept the (quite small) compatibility shim in v2.0.0 - I opened an issue here: https://github.com/qutebrowser/qutebrowser/issues/6082
In the meantime, you could probably symlink it instead:
ln -s /usr/lib/python3/dist-packages/sip.cpython-38-x86_64-linux-gnu.so /usr/lib/python3/dist-packages/PyQt5/
Alternatively, either use the Ubuntu "qutebrowser" package (pre-v2.0.0), or install in a virtualenv instead:
https://github.com/qutebrowser/qutebrowser/blob/master/doc/i...
There's an option there to install a binary Qt/PyQt from PyPI, so you don't need to build anything from source. However, note that it comes without proprietary codec support.
I consider it a rare pleasure.
If curious see also
2018 https://news.ycombinator.com/item?id=18070367
2017 https://news.ycombinator.com/item?id=15458824
2014 https://news.ycombinator.com/item?id=8774609
2018 https://news.ycombinator.com/item?id=18070367
2017 https://news.ycombinator.com/item?id=15458824
2014 https://news.ycombinator.com/item?id=8774609
Nice blast(s) from the past :)
I added the patch for the `--desktop-file-name` flag. It's useful for profile management on Linux. I wrote up a comparison of a couple profile managers for Qutebrowser here:
https://www.reddit.com/r/qutebrowser/comments/l6zj0z/compari...
https://www.reddit.com/r/qutebrowser/comments/l6zj0z/compari...
So many of these types of browsers use webkit; I'm curious why there aren't more that use gecko. Is it a technical issue or a social one?
Chromium/WebKit is available as a library in various ways; Gecko isn't really.
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
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
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
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
Mozilla is actively hostile to anything that smells like "libfirefox". This is a big part of why they killed xulrunner.
This is really sad. IMHO their adoption numbers would not still be plunging if people had a way to insulate themselves from the large, random, and often undesired changes in the UI that are forced upon users with each Firefox security update.
This is really sad. IMHO their adoption numbers would not still be plunging if people had a way to insulate themselves from the large, random, and often undesired changes in the UI that are forced upon users with each Firefox security update.
I'd pay for a book that sheds light on the questionable decisions Mozilla has made throughout the years and the rationale behind them.
From where I'm standing, they seem to consistently make the poorest decisions.
From where I'm standing, they seem to consistently make the poorest decisions.
I suspect mainly technical. Chromium is already embedded everywhere, Gecko a lot less so (I can't even come up with a single modern example, although I'm sure they have to exist). There's probably a lot fewer resources and support if you decide to go the Gecko route.
I also vaguely remember reading somewhere that Gecko is a lot harder to work with for third parties due to unstable APIs and frequent breakage, but don't quote me on on this.
I also vaguely remember reading somewhere that Gecko is a lot harder to work with for third parties due to unstable APIs and frequent breakage, but don't quote me on on this.
Neither Chrome nor Chromium use WebKit.
You're technically correct, because they use Blink, which is a descendant of WebKit.
I'd say it's about as pendantic as insisting that Windows 7 is built on top of Vista as opposed to XP. The prior statement is certainly more direct and strictly accurate, but that doesn't mean the latter statement is automatically false.
I'd say it's about as pendantic as insisting that Windows 7 is built on top of Vista as opposed to XP. The prior statement is certainly more direct and strictly accurate, but that doesn't mean the latter statement is automatically false.
I don't know how to respond to this except to say that anyone operating on either the assumption that Chromium uses WebKit or the belief that Blink being a WebKit fork means that it makes sense not to consider them sufficiently distinct is mistaken one way or another.
People will act like the prospect of maintaining private forks of NPM modules is a major crisis, but then convince themselves—or let other people get away with convincing themselves—that 8+ years of diverging development involving two software giants' investments of billions of dollars of engineering resources poured into implementing their vision of what is one of the most complex and complicated undertakings that exists in software development is somehow no big deal.
(And that's not what "pedantic" means. Both this parenthetical and your comment are examples of pedantry.)
People will act like the prospect of maintaining private forks of NPM modules is a major crisis, but then convince themselves—or let other people get away with convincing themselves—that 8+ years of diverging development involving two software giants' investments of billions of dollars of engineering resources poured into implementing their vision of what is one of the most complex and complicated undertakings that exists in software development is somehow no big deal.
(And that's not what "pedantic" means. Both this parenthetical and your comment are examples of pedantry.)
I actually agree with you. That probably prompts the question: "how on Earth could you possibly hold both of these stances simultaneously without being a big, fat phony?".
Yeah... okay, admittedly it probably doesn't prompt that question because you have better things to be doing, but I have nothing better to do, so I'll explain myself anyway!
The comparison to 7/Vista/XP was not accidental. As you may know, there is an 8 year time gap between the release of 7 and XP. Moreover, Vista was a huge transitional change. Under the hood, 7 and XP are different animals, even if they do share common ancestry and deliver the same baseline functions.
Taking these things into consideration, it's not terribly pedantic to insist that Windows 7 is, in fact, built on top of Vista and not XP. It's still a hair pedantic, but only in the context of this fact being used to correct someone with a less strictly correct (although, I insist, still true) interpretation. That's the feeling I was trying (and failing) to convey with my comparison, which happens to actually be in agreement with your counterpoints.
Yeah... okay, admittedly it probably doesn't prompt that question because you have better things to be doing, but I have nothing better to do, so I'll explain myself anyway!
The comparison to 7/Vista/XP was not accidental. As you may know, there is an 8 year time gap between the release of 7 and XP. Moreover, Vista was a huge transitional change. Under the hood, 7 and XP are different animals, even if they do share common ancestry and deliver the same baseline functions.
Taking these things into consideration, it's not terribly pedantic to insist that Windows 7 is, in fact, built on top of Vista and not XP. It's still a hair pedantic, but only in the context of this fact being used to correct someone with a less strictly correct (although, I insist, still true) interpretation. That's the feeling I was trying (and failing) to convey with my comparison, which happens to actually be in agreement with your counterpoints.
> there is an 8 year time gap between the release of 7 and XP
Which is why the metaphor is off. Safari+WebKit and Chrome+Blink are being developed in parallel and competing with one another. They're not two releases in the same product line where one is the dead forebear and the other a successor.
> it's not terribly pedantic to insist that Windows 7 is, in fact, built on top of Vista and not XP
What? That wasn't the topic. None of this is relevant.
The topic is which engine Chrome is using. Explaining that Chrome doesn't use WebKit isn't pedantic. However, when someone does explain it, for someone else to appear and point out that the engine it uses is forked from WebKit—a nugget of information that changes nothing about the discussion—is pedantic.
I think you're responding at this point for the pleasure of feeling like you're having a conversation, or you're still misinformed about which browsers use which engines. WebKit is not Blink, and Chromium is using the latter, not the former. That's the whole point of this entire digression.
Which is why the metaphor is off. Safari+WebKit and Chrome+Blink are being developed in parallel and competing with one another. They're not two releases in the same product line where one is the dead forebear and the other a successor.
> it's not terribly pedantic to insist that Windows 7 is, in fact, built on top of Vista and not XP
What? That wasn't the topic. None of this is relevant.
The topic is which engine Chrome is using. Explaining that Chrome doesn't use WebKit isn't pedantic. However, when someone does explain it, for someone else to appear and point out that the engine it uses is forked from WebKit—a nugget of information that changes nothing about the discussion—is pedantic.
I think you're responding at this point for the pleasure of feeling like you're having a conversation, or you're still misinformed about which browsers use which engines. WebKit is not Blink, and Chromium is using the latter, not the former. That's the whole point of this entire digression.
Qutebrowser uses webengine.
The Qutebrowser dependency list says it can use either QtWebEngine (Chromium) or QtWebKit (WebKit):
> QtWebEngine, or alternatively QtWebKit (5.212) - This is not recommended due to known security issues in QtWebKit, you most likely want to use qutebrowser with the default QtWebEngine backend (based on Chromium) instead. Quoting the QtWebKit releases page: [The latest QtWebKit] release is based on [an] old WebKit revision with known unpatched vulnerabilities. Please use it carefully and avoid visiting untrusted websites and using it for transmission of sensitive data.
https://www.qutebrowser.org/
To use Geko (or hopefully Quantum) with Qutebrowser you would need a nice QT integration. Poking around a bit, it looks like Mozilla and Nokia did some work on this in 2008, but it doesn’t seem it ever got out of beta:
http://browser.garage.maemo.org/news/10/
> QtWebEngine, or alternatively QtWebKit (5.212) - This is not recommended due to known security issues in QtWebKit, you most likely want to use qutebrowser with the default QtWebEngine backend (based on Chromium) instead. Quoting the QtWebKit releases page: [The latest QtWebKit] release is based on [an] old WebKit revision with known unpatched vulnerabilities. Please use it carefully and avoid visiting untrusted websites and using it for transmission of sensitive data.
https://www.qutebrowser.org/
To use Geko (or hopefully Quantum) with Qutebrowser you would need a nice QT integration. Poking around a bit, it looks like Mozilla and Nokia did some work on this in 2008, but it doesn’t seem it ever got out of beta:
http://browser.garage.maemo.org/news/10/
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
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
Am I misunderstanding what webkit is? QtWebEngine uses chromium, but I thought that necessarily implied a webkit derivative (blink).
blink is basically a fork of a fork of webkit (which is itself a fork of KHTML). It's in the same family, but different.
An ostrich and a woodpecker are similar in a lot of ways, both birds descending from a common ancestor. But I don't think you'd confuse them.
My question still stands. If webkit is a bird and gecko is a reptile, then why are there (relatively) so few reptile browsers? Is it easier to embed engines from the webkit family, or are they popular because chrome and safari are popular?
Largely the former. The efforts to make Gecko easily embeddable, started some 15 years ago, have long floundered.
> Am I misunderstanding what webkit is?
Yes.
Yes.
I love Qutebrowser. I just never had Netflix working on it (Linux Mint). So sadly I still use Firefox.
I hope this release fix what ever the DRM issue is !
I hope this release fix what ever the DRM issue is !
Related: https://news.ycombinator.com/item?id=25849800
The major players of the industry have DRM keys, and browser competition is hindered by only allowing access to DRM protected contents to some other vetted major players.
Nasty situation. But I guess it makes sense from the POV of the entities that want to protect their contents with DRM (if DRM was opensource... its use wouldn't make much sense)
The major players of the industry have DRM keys, and browser competition is hindered by only allowing access to DRM protected contents to some other vetted major players.
Nasty situation. But I guess it makes sense from the POV of the entities that want to protect their contents with DRM (if DRM was opensource... its use wouldn't make much sense)
For some reason, DRM support works just fine (at least last time I tested) with QtWebEngine if it's available (e.g. because Chromium/Chrome is installed on the same system).
This seems relatively unlikely, mainly because the drm issues are likely related to widevine, which google is notoriously picky about who they allow to use it
For some reason, it works just fine (at least last time I tested) with QtWebEngine if it's available (e.g. because Chromium/Chrome is installed on the same system).
This is nothing qutebrowser can fix - DRM/Widevine support is something done entirely by the underlying QtWebEngine and Chromium code.
It's a bit of a pain to set up, but it should be possible to get it to work. Basically, you'll need to get an older Chrome version (corresponding to whatever Qt version you're running), extract the needed .so files from there, and then put them in the right place so QtWebEngine picks them up. Unfortunately, there's almost no feedback when it doesn't work.
Here's a rough guide: https://www.reddit.com/r/qutebrowser/comments/jwb90w/how_do_...
Alternatively, someone there reported installing Google Chrome on the same system did help.
It's a bit of a pain to set up, but it should be possible to get it to work. Basically, you'll need to get an older Chrome version (corresponding to whatever Qt version you're running), extract the needed .so files from there, and then put them in the right place so QtWebEngine picks them up. Unfortunately, there's almost no feedback when it doesn't work.
Here's a rough guide: https://www.reddit.com/r/qutebrowser/comments/jwb90w/how_do_...
Alternatively, someone there reported installing Google Chrome on the same system did help.
Qutebrowser runs on top of Blink, which is the same guts that are in Chrome. So if Widevine is packaged for some other browser that is available on your distro, you can pass in the QT arg
"widevine-path=/path/to/google/chrome/WidevineCdm/_platform_specific/linux_x64/libwidevinecdm.so"
and it should work. This even works on NixOS, although you have to pull the relevant path out of the Nix store, and I don't know a good way to do that automatically that can fit inside a qutebrowser config.
"widevine-path=/path/to/google/chrome/WidevineCdm/_platform_specific/linux_x64/libwidevinecdm.so"
and it should work. This even works on NixOS, although you have to pull the relevant path out of the Nix store, and I don't know a good way to do that automatically that can fit inside a qutebrowser config.
QtWebEngine already detects a variety of places automatically:
https://github.com/qt/qtwebengine/blob/v5.15.2/src/core/cont...
So that flag is only needed if the file is in some strange place (like I'm guessing is the case on NixOS).
https://github.com/qt/qtwebengine/blob/v5.15.2/src/core/cont...
So that flag is only needed if the file is in some strange place (like I'm guessing is the case on NixOS).
I really love Qutebrowser. I'm mostly missing autofill/password manager integration, but that's because I'm too lazy to learn to write scripts for this.
I sometimes feel lost at work without it, and even Vimium doesn't feel as good to me.
I'd be glad to get ideas from anyone willing to share confs.
And the unbeatable openness and availability of The-Compiler is really appreciated!
I sometimes feel lost at work without it, and even Vimium doesn't feel as good to me.
I'd be glad to get ideas from anyone willing to share confs.
And the unbeatable openness and availability of The-Compiler is really appreciated!
> I really love Qutebrowser. I'm mostly missing autofill/password manager integration, but that's because I'm too lazy to learn to write scripts for this.
FWIW there are various existing ones you could use: https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
> And the unbeatable openness and availability of The-Compiler is really appreciated!
Thanks for the nice words! :)
FWIW there are various existing ones you could use: https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
> And the unbeatable openness and availability of The-Compiler is really appreciated!
Thanks for the nice words! :)
I really like this browser. The reason I don't use it is kind of silly: Scrolling with j/k works so much more nicely with vimium in firefox. It's such a small complaint, but it really is what is keeping me away.
Probably this issue is relevant: https://github.com/qutebrowser/qutebrowser/issues/4768
It looks really cool, will definitely check it out;
I hate that it's based on Chromium though, and Qutebrowser privacy related settings also seem quite limited compared to Firefox... (and even compared to Chromium.)
I hate that it's based on Chromium though, and Qutebrowser privacy related settings also seem quite limited compared to Firefox... (and even compared to Chromium.)
> I hate that it's based on Chromium though
There aren't really many alternatives. The main one is WebKitGTK, but that comes with its own set of issues (mostly performance/compatibility). You can use qutebrowser with QtWebKit as well, but I wouldn't recommend it - it's based on a 2018 WebKit with many known security issues: https://github.com/qtwebkit/qtwebkit/releases
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
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
> and Qutebrowser privacy related settings also seem quite limited compared to Firefox... (and even compared to Chromium.)
Can you be more specific? Pretty much anything that's possible to expose (either via a QtWebEngine API or via Chromium commandline arguments) is exposed. Certain things (like deleting cookies belonging to a tab when it's closed) just aren't possible without implementing them in QtWebEngine first unfortunately.
FWIW there's an overview here: https://github.com/qutebrowser/qutebrowser/issues/4045
There aren't really many alternatives. The main one is WebKitGTK, but that comes with its own set of issues (mostly performance/compatibility). You can use qutebrowser with QtWebKit as well, but I wouldn't recommend it - it's based on a 2018 WebKit with many known security issues: https://github.com/qtwebkit/qtwebkit/releases
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
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
> and Qutebrowser privacy related settings also seem quite limited compared to Firefox... (and even compared to Chromium.)
Can you be more specific? Pretty much anything that's possible to expose (either via a QtWebEngine API or via Chromium commandline arguments) is exposed. Certain things (like deleting cookies belonging to a tab when it's closed) just aren't possible without implementing them in QtWebEngine first unfortunately.
FWIW there's an overview here: https://github.com/qutebrowser/qutebrowser/issues/4045
Thanks for your reply, the basic things i was missing at a first glance:
- Could not find a way/command to simply clear ALL the cache (cookies, cached images and files, Database storage, etc.)
- The ultimate goal would be some way to replace the functionality of "Temporary Containers" or alternatively "Cookie Autodelete" (you keep all the history, but everything else is in Incognito mode except for whitelisted sites.)
- Can't disable WebRTC (= unique device id can always be tracked)
I can understand the choice for Chromium btw. Although i can't bring myself to using/supporting Google's monopoly... so i'll stick to Firefox as my main browser.
Great project, keep it up :)
- Could not find a way/command to simply clear ALL the cache (cookies, cached images and files, Database storage, etc.)
- The ultimate goal would be some way to replace the functionality of "Temporary Containers" or alternatively "Cookie Autodelete" (you keep all the history, but everything else is in Incognito mode except for whitelisted sites.)
- Can't disable WebRTC (= unique device id can always be tracked)
I can understand the choice for Chromium btw. Although i can't bring myself to using/supporting Google's monopoly... so i'll stick to Firefox as my main browser.
Great project, keep it up :)
> Could not find a way/command to simply clear ALL the cache (cookies, cached images and files, Database storage, etc.)
That one is indeed because most of those things are opaque to qutebrowser. They're handled by the underlying QtWebEngine/Chromium, and only for a few of those things there's a way for qutebrowser to delete them. There's an issue about it here: https://github.com/qutebrowser/qutebrowser/issues/58 - but many things probably can't be done, or only in a hackish way (e.g. by qutebrowser reading/manipulating those internal Chromium files, before it starts up fully).
You can however remove ~/.cache/qutebrowser and ~/.local/share/qutebrowser/webengine/ manually.
> The ultimate goal would be some way to replace the functionality of "Temporary Containers" or alternatively "Cookie Autodelete" (you keep all the history, but everything else is in Incognito mode except for whitelisted sites.)
Via qutebrowser's `--temp-basedir` (or `--basedir`) flag, you can already start an isolated instance - but indeed the history won't be shared with the main instance (and neither will e.g. the config, but there's the --config-py flag).
There are also some "profile managers" which are based on the `--basedir` flag: https://www.reddit.com/r/qutebrowser/comments/l6zj0z/compari...
Finally, I'd indeed like to have a container-like feature integrated into qutebrowser itself in some way: https://github.com/qutebrowser/qutebrowser/issues/4102 - automatically switching containers based on the URL unfortunately won't be possible, but I think even just launching a new window with a different storage path (i.e. profile) would provide a lot of value.
> Can't disable WebRTC (= unique device id can always be tracked)
I think to fully disable it, you'll need to rebuild QtWebEngine. As far as I know, this is a Chromium limitation. Can you elaborate on "unique device id" though? I'm only aware of WebRTC leaking internal IPs, which can be prevented via the `content.webrtc_ip_handling_policy` setting.
> Great project, keep it up :)
Thanks for all the feedback, I really appreciate it!
That one is indeed because most of those things are opaque to qutebrowser. They're handled by the underlying QtWebEngine/Chromium, and only for a few of those things there's a way for qutebrowser to delete them. There's an issue about it here: https://github.com/qutebrowser/qutebrowser/issues/58 - but many things probably can't be done, or only in a hackish way (e.g. by qutebrowser reading/manipulating those internal Chromium files, before it starts up fully).
You can however remove ~/.cache/qutebrowser and ~/.local/share/qutebrowser/webengine/ manually.
> The ultimate goal would be some way to replace the functionality of "Temporary Containers" or alternatively "Cookie Autodelete" (you keep all the history, but everything else is in Incognito mode except for whitelisted sites.)
Via qutebrowser's `--temp-basedir` (or `--basedir`) flag, you can already start an isolated instance - but indeed the history won't be shared with the main instance (and neither will e.g. the config, but there's the --config-py flag).
There are also some "profile managers" which are based on the `--basedir` flag: https://www.reddit.com/r/qutebrowser/comments/l6zj0z/compari...
Finally, I'd indeed like to have a container-like feature integrated into qutebrowser itself in some way: https://github.com/qutebrowser/qutebrowser/issues/4102 - automatically switching containers based on the URL unfortunately won't be possible, but I think even just launching a new window with a different storage path (i.e. profile) would provide a lot of value.
> Can't disable WebRTC (= unique device id can always be tracked)
I think to fully disable it, you'll need to rebuild QtWebEngine. As far as I know, this is a Chromium limitation. Can you elaborate on "unique device id" though? I'm only aware of WebRTC leaking internal IPs, which can be prevented via the `content.webrtc_ip_handling_policy` setting.
> Great project, keep it up :)
Thanks for all the feedback, I really appreciate it!
I will have a look at the profile managers, that might be quite useful for now, thanks for the tips;
As for the "unique device id", you can check it here where they also describe how to turn it off in Firefox: https://browserleaks.com/webrtc
As for the "unique device id", you can check it here where they also describe how to turn it off in Firefox: https://browserleaks.com/webrtc
If anyone has any hints on getting qutebrowser to not suck up battery and CPU on macOS Big Sur it would be much appreciated. Maybe things will smooth out in 2.0?
Some of those issues might be caused by the underlying QtWebEngine. For others, qutebrowser might be responsible (I'm mainly thinking of https://github.com/qutebrowser/qutebrowser/issues/5376 which might be relevant).
In my day-to-day work, I only use Linux - so the Windows/macOS releases are pretty much "best effort" I'm afraid, until someone steps up to fix platform-specific issues there.
In my day-to-day work, I only use Linux - so the Windows/macOS releases are pretty much "best effort" I'm afraid, until someone steps up to fix platform-specific issues there.
Any way to use a password manager like 1Password with this?
For Lastpass, I use a Rofi-based frontend on Linux.
A keybinding pops up a search box, I search for the entry I want and paste it into Qutebrowser.
I like that it works outside the browser-- so I can unlock it once and works across all browsers.
Also, I disable autofill anyway. Lastpass has had multiple security issues with their autofill feature in the past and I don't trust it.
A keybinding pops up a search box, I search for the entry I want and paste it into Qutebrowser.
I like that it works outside the browser-- so I can unlock it once and works across all browsers.
Also, I disable autofill anyway. Lastpass has had multiple security issues with their autofill feature in the past and I don't trust it.
FWIW I use something similar for KeePassXC: https://github.com/firecat53/keepmenu
I don't know, but FYI it seems someone wrote a script for 1Password: https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
It works well with pass.
Did you do anything to integrate it or just solve pass outside of qb?
You can use the userscripts : https://github.com/qutebrowser/qutebrowser/tree/master/misc/...
For example for pass:
config.bind('some key', 'spawn --userscript qute-pass')
For example for pass:
config.bind('some key', 'spawn --userscript qute-pass')
Sessions (:session-save) have not been saving properly in v1.14, a known issue related to QT. No news about it in changelog.
There was a note on the first startup tab for me, with a lonk to this ticket: https://github.com/qutebrowser/qutebrowser/issues/5359
I'm afraid I don't really have much news to share about that. It requires a complete rewrite of session handling and the on-disk session format, and that's just something I haven't gotten around to finishing yet.
I've updated the related issue earlier this week though: https://github.com/qutebrowser/qutebrowser/issues/5359#issue...
FWIW, saving isn't the problem - restoring a tab's back/forward history from the saved file is.
I've updated the related issue earlier this week though: https://github.com/qutebrowser/qutebrowser/issues/5359#issue...
FWIW, saving isn't the problem - restoring a tab's back/forward history from the saved file is.
Thanks for the reply, The-Compiler, and for your project.
I assumed my problem was related to the QT issue because it started at the same time, but I was wrong. It's just a configuration mistake. I had `session.default_name` set to no value, and because I typically exit qutebrowser with "ZZ" (`:quit --save`), the last session I created was getting overwritten by the contents of my last-viewed windows.
Wouldn't have checked if you hadn't responded. Very grateful.
I assumed my problem was related to the QT issue because it started at the same time, but I was wrong. It's just a configuration mistake. I had `session.default_name` set to no value, and because I typically exit qutebrowser with "ZZ" (`:quit --save`), the last session I created was getting overwritten by the contents of my last-viewed windows.
Wouldn't have checked if you hadn't responded. Very grateful.
Does it support uBlockOrigin/uMatrix?
It doesn't support WebExtensions (i.e. Chrome/Firefox extensions) unfortunately - see the FAQ in https://github.com/qutebrowser/qutebrowser/issues/30 for some details.
However, the new built-in adblocker does a big part of what uBlockOrigin does. As for uMatrix, there's https://gitlab.com/jgkamat/jmatrix (though it's a rather unofficial hack, and I have no idea if it still works with v2.0.0).
I'd really like to integrate something uMatrix-like (with nice keyboard usage) into qutebrowser some day, but so far I didn't get around to it: https://github.com/qutebrowser/qutebrowser/issues/28
However, the new built-in adblocker does a big part of what uBlockOrigin does. As for uMatrix, there's https://gitlab.com/jgkamat/jmatrix (though it's a rather unofficial hack, and I have no idea if it still works with v2.0.0).
I'd really like to integrate something uMatrix-like (with nice keyboard usage) into qutebrowser some day, but so far I didn't get around to it: https://github.com/qutebrowser/qutebrowser/issues/28
Thanks for the answers.
> > Does it support uBlockOrigin/uMatrix?
> It doesn't support WebExtensions (i.e. Chrome/Firefox extensions) unfortunately
JFTR, uBlockOrigin available as non-WebExtension for legacy Firefox/PaleMoon.[0]
[0] https://github.com/gorhill/uBlock-for-firefox-legacy
> > Does it support uBlockOrigin/uMatrix?
> It doesn't support WebExtensions (i.e. Chrome/Firefox extensions) unfortunately
JFTR, uBlockOrigin available as non-WebExtension for legacy Firefox/PaleMoon.[0]
[0] https://github.com/gorhill/uBlock-for-firefox-legacy
Fair point - though that's not supported by qutebrowser either, and most probably never will be.
The virus scanner on my work computer flags quotebrowser as malware and deletes it outright.
I'm honestly not sure how this comment helps anyone. Have you tried contacting your employer's IT support or the antivirus vendor about this issue?
Unless you think it actually contains malware?
Unless you think it actually contains malware?
Like mentioned by toyg in another reply, AV engines are really overzealous when it comes to PyInstaller executables :(
Not much I can do about that, but I opened https://github.com/qutebrowser/qutebrowser/issues/6081 to send a couple of appeals whenever I'm bored enough to do so.
Not much I can do about that, but I opened https://github.com/qutebrowser/qutebrowser/issues/6081 to send a couple of appeals whenever I'm bored enough to do so.
That is because you downloaded quotebrowser instead of qutebrowser. You are welcome.
Let me know when they finally fix their SOCKS Proxy issue.
What's the issue with using a SOCKS proxy? I do it all the time in qutebrowser.
If you want anything to be fixed, you'll really need to be more specific... ¯\_(ツ)_/¯
I did/continue to have issues with qt-webengine though, like 144hz monitor with qt webengine is limited to 60hz but these things are unrelated to qutebrowser. In fact most of my "bugs" can be related to upstream qt webengine and wayland support. I feel bad for the authors of qutebrowser for so often getting issues that is actually an upstream bug in qt. It doesn't help that qt webengine work is rather slow (imo)
There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great. My colleagues sometimes were amazed at how fast I could navigate across the browser all thanks to this great software
Thank you qutebrowser!