Love using qutebrowser. Really an amazing opensource browser!
The only extension necessary for me was adblocking and now it's even better!
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
> 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...
> 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.
> 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.
> 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.
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.
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.
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.
> 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.
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.
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 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.
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:
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.
>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.
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]
- 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.)
> 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.
- 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 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.
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...
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.
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.
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.
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 ?
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.
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 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:
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 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 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.
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.)
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
> 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.
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.
[+] [-] wernerb|5 years ago|reply
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!
[+] [-] 3np|5 years ago|reply
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.
[+] [-] jamesbvaughan|5 years ago|reply
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...
[+] [-] RMPR|5 years ago|reply
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.
[+] [-] The-Compiler|5 years ago|reply
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!
[+] [-] BiteCode_dev|5 years ago|reply
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.
[+] [-] Semaphor|5 years ago|reply
> 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.
[+] [-] leephillips|5 years ago|reply
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-Compiler|5 years ago|reply
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.
[+] [-] dijit|5 years ago|reply
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...
[+] [-] bendiksolheim|5 years ago|reply
[+] [-] notagoodidea|5 years ago|reply
[+] [-] The-Compiler|5 years ago|reply
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
[+] [-] oftenwrong|5 years ago|reply
[+] [-] jarbus|5 years ago|reply
[+] [-] The-Compiler|5 years ago|reply
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...
[+] [-] v8engine|5 years ago|reply
I downloaded the prebuilt windows binary from https://github.com/qutebrowser/qutebrowser/releases
[+] [-] toyg|5 years ago|reply
I've also seen some AVs having an issue with QT dlls, probably because some malware used them at some point.
[+] [-] jnxx|5 years ago|reply
But it is a good reason to only run stuff that has a pgp-signed checksum.
[+] [-] simias|5 years ago|reply
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 guess I'll retry in a little while...[+] [-] chaorace|5 years ago|reply
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...
[+] [-] ognarb|5 years ago|reply
[+] [-] lcrz|5 years ago|reply
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.
[+] [-] albertzeyer|5 years ago|reply
- 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.
[+] [-] Timothee|5 years ago|reply
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|5 years ago|reply
- 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.
[+] [-] The-Compiler|5 years ago|reply
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...
[+] [-] alexfrydl|5 years ago|reply
[+] [-] Abishek_Muthian|5 years ago|reply
But the development is slow, last major release was in Mar 2019.
[1]https://userbase.kde.org/Falkon
[+] [-] lk0nga|5 years ago|reply
[+] [-] The-Compiler|5 years ago|reply
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/...
[+] [-] chaorace|5 years ago|reply
[+] [-] fowlie|5 years ago|reply
[+] [-] The-Compiler|5 years ago|reply
[+] [-] xuhu|5 years ago|reply
[+] [-] The-Compiler|5 years ago|reply
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:
(Though you'll then run into the next issue, apparently Ubuntu 20.04 doesn't have importlib_resources packaged: https://github.com/qutebrowser/qutebrowser/issues/6084 ...)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.
[+] [-] Y_Y|5 years ago|reply
[+] [-] dang|5 years ago|reply
2018 https://news.ycombinator.com/item?id=18070367
2017 https://news.ycombinator.com/item?id=15458824
2014 https://news.ycombinator.com/item?id=8774609
[+] [-] markstos|5 years ago|reply
https://www.reddit.com/r/qutebrowser/comments/l6zj0z/compari...
[+] [-] cout|5 years ago|reply
[+] [-] The-Compiler|5 years ago|reply
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
[+] [-] simias|5 years ago|reply
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.
[+] [-] Evidlo|5 years ago|reply
[+] [-] Phenix88be|5 years ago|reply
I hope this release fix what ever the DRM issue is !
[+] [-] pm3003|5 years ago|reply
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!
[+] [-] vcxy|5 years ago|reply
[+] [-] DavideNL|5 years ago|reply
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.)
[+] [-] The-Compiler|5 years ago|reply
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
[+] [-] basilisks|5 years ago|reply
[+] [-] The-Compiler|5 years ago|reply
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.