Qutebrowser kikestarter

Read more here: kickstarter.com/projects/the-compiler/qutebrowser-v10-with-per-domain-settings?ref=5xz8ps

This sounds pretty nice. One of the biggest things qutebrowser lacks right now is noscript-like functionality.

Other urls found in this thread:

github.com/qutebrowser/qutebrowser/issues/335
github.com/annulen/webkit/wiki
github.com/qutebrowser/qutebrowser/graphs/contributors
twitter.com/SFWRedditVideos

That's something I've wanted for years. All other browsers are just skeletons that rely on addons for any functionality. I mean, uMatrix is great, but it's time to have a browser with some meat on its bones.

Does it have an HTTPS Everywhere-like feature or config yet?

Doesn't seem to as of yet, but it has been talked about here:

github.com/qutebrowser/qutebrowser/issues/335

There have been some ideas thrown around, but nothing complete as of yet

Hopefully they can include it in the per-domain settings feature. I'm interested in knowing how this config.py will be managed. I imagine someone will make a userscript that scrapes lists used by uBlock Origin, uMatrix, HTTPS Everywhere, etc and drops them in the user config. If proper plugin support is added, you might get a convenient GUI like uMatrix to override on the fly.

config.py sounds very promising. It's nice to see a browser developer working on advanced features rather than trying to simplify everything as much as possible. If this leads to being able to do a lot of the things that firefox addons provide it will be an easy decision to switch to qutebrowser full time.

holy fucking bloat, but this is the new normal.
everything is shit

it's finally happening. now all it needs to do is stop freezing on random intensive sites.

pick one

The config.py is only for more advanced configuration - the mentioned GUI config file will have per-domain settings as well, and there will be commands/keybindings for common scenarios like enabling/disabling javascript for the current host.

The underlying backends (i.e. rendering/network/etc. stack) are written in C++. Compared to them, the Python layer (i.e., qutebrowser) is very thin. Still less bloat than Chromium/Firefox :P

What backend are you using? With the QtWebKit backend, I'm aware of some freezes (mostly GStreamer-related, with audio streams), but they're outside of my control.

I'd really recommend to switch to QtWebKit-NG (see github.com/annulen/webkit/wiki ) or QtWebEngine (start with --backend webengine, or remove QtWebKit, or wait for a config option with the new config), which generally run much smoother.

Can't wait for this update, will probably make qutebrowser my main browser when it is released. Right now I switch between qutebrowser and firefox

I'm going to have to try this. I haven't noticed the freezing problems described by the other poster, but I'm interested in how the development of webengine in qutebrowser has been going.

That backend trick works, but I thought that worked by using the older backend and not the new one. If that's supposed to be the new one though, that's fine.

webengine is definitely the new one.

I've always wanted to use qutebrowser but not having https everywhere and uMatrix/NoScript has always bothering, all these changes are great, the possibility to add custom css for websites individually like stylish is also great, youtube won't burn my eyes anymore. I'm definitely making the switch after this.

And so is webkit-ng for the people who don't want to infest themselves with chromium botnet.

What exactly is botnet about the engine? Or are you just talking out of your ass?

Why?
A browser isn't a thing you do once and then forget about. It requires constant maintenance.
Wouldn't Patreon have been a better idea?

And that's been happening over the last 3.5 years: github.com/qutebrowser/qutebrowser/graphs/contributors

The crowdfunding isn't for the project on itself, but for a particular feature in an existing project which takes some longer uninterrupted time.

I did a little checking with strace a while ago, and I didn't find any suspicious network traffic, for what it's worth.

That's what I figured. I can understand having a problem with the engine in the sense that if everyone starts using the Chromium engine all there will be is that 1 engine with no competition since web developers are lazy Pajeets that can't code for shit and would love to drop support for every other browser on their sites so they don't have to actually test. But to call it botnet requires some proof.

I was talking out the ass, don't mind me.
I dislike it for the mere merit of being Chromium, an almost omnipotent browser with zero to no competition, of whose devs wouldn't mind having you download a binary for voice recognition or anything else. The engine being fine now doesn't mean it'll be in the future, and given google's track record, I don't trust it.

Understandable, I wish sjwzilla would hurry up with servo so there were more options. Sadly, given sjwzilla's track record it will probably be scrapped long before it's finished because they spend all their money virtue signaling.