Qutebrowser – A keyboard-driven, Vim-like browser based on PyQt5 | Hacker News Reader

Qutebrowser – A keyboard-driven, Vim-like browser based on PyQt5

qutebrowser.org

202 pointstomxor107 comments

One of the things that can really make or break a project for me is how its developers behave towards the users. The developer of this project is a really upstanding, responsive, kind human being. I think his project deserves all the attention it can get.

I have used qutebrowser as my primary browser on Linux for years. I have no complaints. In fact, qutebrowser runs smoothly on some of my older machines where Firefox struggles to run.

Unfortunately, I also use Windows a lot. QTWebEngine builds for Windows do not have some codecs most of the internet expects you to have, and some js laden sites seem to perform poorly on the Windows builds. Both of these problems are with the qtwebengine project and there's nothing qutebrowser can do about that. Even so, I would recommend Windows users give it a try anyway.

I'm so pleased that this is the top-voted comment! (And I totally endorse it.)

Props to TheCompiler, even before Qutebrowser I remember him helping people out on freenode#python. I've backed his latest kickstarter and there were plenty of updates and cool swag. He's also very active reddit, irc and mastodon.

Not sure where he finds so much time and affords to do what he does living on one of the most countries in the world (Switzerland) but dude is truly inspiring!

I truly hope he doesn't ever leave FLOSS.

Thanks! On the flip side, I sometimes feel like I never really have time for coding because I'm putting a lot of effort into community things, for better or worse :)

As for affording it: I still live with my mother (I'm 25 and a full-time student), so that works out well so far.

Not sure yet what'll happen after the studies, from how things look like now I might end up moving to my girlfriend's place in Vorarlberg (Austria, but close to the Swiss border) where things are cheaper, and try to live off qutebrowser donations and some freelancing gigs. We'll see!

You do awesome work Compiler, I'm sure people will continue to fund you for more open source work in the future (if that's what you want)... that said - you are young and have so many opportunities after your studies, keep an open mind as to what _you_ want and good luck with everything.

I wish I could have the best of all worlds here - a minimal browser like qutebrowser but also built on the latest Chromium (or whatever engine you prefer, something built on Servo would be cool) but sadly even the qt5-webengine backend is stuck back in Chromium 65.X which was released at the very beginning of this year

To be fair, I've not done enough research to KNOW whether or not that poses any real security risk but it's still a concern. There's also the FOMO that I'm missing some modern browser features that I can only test out in other browsers :/

It's OSS though, so I should probably shut up and roll up my sleeves

> but sadly even the qt5-webengine backend is stuck back in Chromium 65.X which was released at the very beginning of this year

Good shout, I did not realise this, however the last release (5.11.2) was relatively recently in June... however I can't find release details for qtwebengine, where are you getting your release information from RE chromium?

This was the main reason I was attracted to this browser because the old webkit2 based vim-like browsers were hopelessly out of date to point of being very dangerous.

Yeah, they don't call out what version they're on without some digging. I had to actually download the browser and check manually

> This was the main reason I was attracted to this browser because the old webkit2 based vim-like browsers were hopelessly out of date to point of being very dangerous.

Same here. I had to forgo other browsers I quite like because of their older versions of webkit

If the user-agent string is to be trusted the latest version released in June is still based on chrome 65.x like you said... :/ it's not terrible but not great either.

However they do claim to backport security patches on their front page so it should technically be secure.

I suppose it would take a lot of repetetive effort going through the same process to pull apart chromium each major release, so perhaps they settle on backporting patches in between larger breaks.

Yeah, I recall them saying they need something like two man-months for each Chromium release to adapt (the changed lines in the imported Chromium source is usually somewhere around a couple of million...).

> the changed lines in the imported Chromium source is usually somewhere around a couple of million.

Yeah that sounds truly horrifying, I guess they must employ some degree of automation though.

It's in their documentation (but a bit hidden): http://doc.qt.io/qt-5/qtwebengine-overview.html#qt-webengine... (This version of Qt WebEngine is based on Chromium version ...).

I usually check their script, which also lets you switch between versions easily: http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts...

And I also have an overview here: https://github.com/qutebrowser/qutebrowser/blob/master/quteb...

The main thing that I miss when using Qutebrowser is extensions.

On Chrome I rely on 3 extensions: 1Password, uBlock Origin and Vimium. I obviously don't need Vimium on Qutebrowser. I could possibly get by without 1Password if I switched to something like Pass. However, I can't give up uBlock Origin. I run it in "medium mode" (3rd party frames/js blocked by default) and I can't give this up.

I would pay decent money to be able to run uBlock Origin on Qutebrowser.

Have you thought about using your hosts file to ads?

qutebrowser has a hosts-based adblocker built in, so that probably won't make a big difference.

I saw this in the qutebrowser quick start page:

Run :adblock-update to download adblock lists and activate adblocking

qutebrowser comes with a built-in adblocker, but that's quite basic (it only blacklists hosts, like a /etc/hosts file would).

I'd absolutely like something like uMatrix in qutebrowser (see [1]), and since I recently started work on a plugin API[2], that'll hopefully happen soon-ish.

As for password manager integration, check qutebrowser's userscripts[3] (which are unrelated to Greasemonkey scripts), but a plugin API should provide a better foundation for that as well.

[1] https://github.com/qutebrowser/qutebrowser/issues/28

[2] https://lists.schokokeks.org/pipermail/qutebrowser-announce/...

[3] https://github.com/qutebrowser/qutebrowser/tree/master/misc/...

I'm a happy qutebrowser user, too; but I too would've liked some password manager integration (to the point where I considered investing some time into the Keepass RPC API, since that's my pwd manager of choice).

However, since I stumbled about this project, I've got no need for that anymore: https://github.com/purduelug/passhole

I really like the suckless approach to GUIs in this case. Yes, you don't get stuff like automatic url matching with this, and you have to manually add new entries, but its functionality is works great for me nontheless.

Maybe, there's also an easy way for you to get (or write) a dmenu interface for 1password?

seems like the 1password cli could be used to avoid needing a plugin?

With 5.12 today you get Chrome 69, but your point is valid. I use CEF [0] because it tracks closely with Chromium release timelines/versions so I'm never far behind on security fixes unless I'm lazy. With a bit of plumbing, it works with Qt just fine.

0 - https://bitbucket.org/chromiumembedded/cef

I have considered using CEF as well (via cefpython), but the main deal breaker was that it isn't packaged anywhere - so I'd need to ship my own copy of it with qutebrowser, which is usually not something you can do with Linux distribution packages.

> so I'd need to ship my own copy of it with qutebrowser, which is usually not something you can do with Linux distribution packages.

You definitely can. I do: https://cretz.github.io/doogie/. Prebuilt versions are available at http://opensource.spotify.com/cefbuilds/index.html. In fact, I'd say shipping with the browser is ideal for a few reasons. It's not a lib that should be shared across the system IMO.

Note the "Linux distribution packages", as in "your application being packaged by Linux distributions". That's pretty much not going to happen if you ship your own engine.

Could you elaborate why you'd prefer shipping it with the browser rather than sharing it?

Because I'm the only one using it, it occassionally has backwards incompatible API changes, most browsers ship with their own engines, it has a compilation step anyways for the wrapper, it is self-contained, etc. How do these packages ship Chrome or FF? They don't make them ship Blink or Gecko as shared system-wide libs IIRC. My browser is no different. (now, Qt on the other hand, is a different story, like Gtk or whatever)

Chromium and Firefox are kind of an exception there, as they are big enough for distributions to justify bundling the engine, and they are also the upstream projects where those engines are developed.

But you can't rely on any external entity's free service. Spotify are a great example of an org who'll deprecate it (if you are lucky) this week and then shut it down the next. Or maybe suddenly change it underneath you. If you are going to do this you must be able to build and host it yourself. And that's the hassle that was alluded to.

I don't rely on it, I leverage it because it's there. Of course I can build it and host it myself. But when compiling Chromium, prebuilt libs have value for quick iteration.

Fair enough. I guess it's not tricky to build for those platforms so you could get a replacment going quickly. An arm build would be useful though.

What's wrong with Chromium 65?

That the newest stable release is Chromium 69, and ideally you wouldn't want to lag behind that.

It's kind of irritating that we're always trying to keep up with the latest version. In a way, it's actually putting the power into their hands. Making it easier for them to get away with sleazier stuff because the majority are on the most recent version.

And because everyone's on the latest version, it's harder for individuals to downgrade or stay on old versions for longer without getting obsoleted.

It's actually closing the web. The excuse for aggressive upgrades & auto-updates are mainly for security purposes, with the side benefit of reducing the work of web developers. But on the flip side, it's actually huge centralization move.

While the Chromium version in QtWebEngine only gets updated for major releases (all ~6 months), they do backport security fixes. The latest 5.11.2 release comes[1] with fixes up to Chromium 68.0.3440.75, and the upcoming 5.12 release (scheduled[2] for November) updates[3] the baseline to Chromium 69.

It's a bigger issue if you're on a distribution like Debian Stable, which ships an ancient Qt version without security updates[4]. There, you get Qt 5.7.1 based on Chromium 49 (2016-03-02) with security fixes up to 54 (2016-10-19)... I'll probably drop support for that soon even if it's annoying for some Debian Stable users, but people really should stop using such old QtWebEngine versions.

Missing web features usually isn't much of a problem in my experience, as most sites still wait a bit before they start using them.

FWIW I agree something based on Servo would be cool, and as soon as there's some project making Servo embeddable from Python with Qt integration, I'll get my hands dirty to at least have a proof of concept!

[1] http://code.qt.io/cgit/qt/qtwebengine.git/tree/dist/changes-...

[2] https://wiki.qt.io/Qt_5.12_Release

[3] http://code.qt.io/cgit/qt/qtwebengine.git/tree/tools/scripts...

[4] https://www.debian.org/releases/stable/amd64/release-notes/c... - only mentions QtWebKit, but applies to QtWebEngine too

Considering that 5.12 is an LTS release, they are evaluating to separate WebEngine from the normal QT release cycle.

> This is still under research, but there seem to be quite tangible benefits from carving out Qt WebEngine to a separate item. Current thinking it that as a separate item we should be able to release Qt WebEngine every three months, following nicely the schedule of Chromium releases every six weeks. For Qt 5.12 LTS users this would mean the possibility to get not only the security updates, but a full new Chromium version supported on top of the long-term-supported release of Qt.

https://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/

I doubt that'll happen with Qt 5.12, but it hopefully will with Qt 6: https://bugreports.qt.io/browse/QTBUG-63235

Been using qutebrowser as my daily browser quite happily since summer 2017. I still have chromium as a backup browser in case of wierd webpage/embedded banking apps decides to dislike qutebrowser. Quite happy honestly, and the progress on the project itself is going steadily forwards.

A plugin API seems to be in the works with a recent announcement; https://lists.schokokeks.org/pipermail/qutebrowser/2018-Sept...

It seems interesting, is is compatible in any way with BitWarden[1], it has a CLI[2] extension that can probably be used in Qutebrowser.

Does anyone know if it is possible integrate? If so, how difficult would it be?

[1] https://bitwarden.com/

[2] https://github.com/bitwarden/cli/

You could probably write a qutebrowser userscript similar to the other password scripts which already exist:

https://github.com/qutebrowser/qutebrowser/tree/master/misc/...

Hopefully, things will also get easier in the future with the upcoming plugin API:

https://lists.schokokeks.org/pipermail/qutebrowser-announce/...

Anybody want to voice their preferences for post-Firefox 57 based plugins like this? There seem to be a lot of options...

Tridactyl. Vs saka or vim vixen it has its native messenger feature which lets it interact with the host OS. Example press a key to edit the current input box in your editor or hit a key and show hint keys and open the selected link in mpv.

I used vimium on Chrome for years and since web extensions became available on Firefox have started using it there too. Gets my vote.

https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/

Lack of Vimium stopped me from even attempting to switch back from Chrome to Firefox.

Can't live without Vimium.

Did you not know that the old Firefox had much more functional vim emulation add ons?

I think it's unfair to describe Vimium as less functional. They do less but they do it well with a modern looking UI.

I've settled on Saka Key. It's decent, I think as good as it can get with WebExtensions and having to inject all your functionality as JavaScript into the page after/while it loads.

Look in the settings for VimFX and Vimium preset schemes, I don't really change anything else.

Note that Saka Key currently is unmaintained: https://github.com/lusakasa/saka-key/issues/171

Tridactyl. Very vim-like.

> There seem to be a lot of options...

I'm always quite amused by this. The only reason we made Tridactyl was because there was an issue on the Vimperator GitHub about it dying with FF57 and no-one seemed like they were going to step up and make something, so we reluctantly did.

Then, come November, Saka-key, Vim Vixen and VVimpulation all came out of nowhere.

Haha exactly. I was quite unhappy about the lack of options in the beginning of this year and just went with Vimium, which I don't really like. This thread led me to realize that so many projects have come up out of the blue. Tridactyl is definitely the most functionally complete one and I'll now switch to it. Thanks for the work.

The "Similar projects" section [0] contains a concise list of similar browsers, like luakit and surf. Although I've used these two extensively, I always eventually came back to Firefox or Chrome, due to some obscure inconveniences. I hope others are having better luck. I'd sure like to one day see a true variety of popularly used browsers.

[0] https://github.com/qutebrowser/qutebrowser#similar-projects

I honestly clicked the link in your comment hoping to read a compiled list of obscure inconveniences that have prevented you from using alternative browsers. Any hope we can learn some of these issues? ;P

I actually have the opposite list, the reasons why I can't use traditional browsers with plugins:

  - Keybinds are lost when page is loading or on special pages, which is a huge break in flow
  - Some keys cannot be bound (eg, unbinding Ctrl-q, binding Ctrl-w)
  - Lack of options when customizing the UI (I can't get my nyan fix, can't move tabs to the bottom/right of the screen)
  - The omnibar (firefox, chrome, vimium) feels extremely slow, especially compared to lighter weight history searches.
  - (sometimes) lack of an insert/passthrough mode, to send keys to js running on the page
  - Inability to integrate cleanly with the rest of my system (:spawn mpv {url}, qb userscripts)
  - Much harder to hack on the browser itself

Integration with your system is easy with native messaging. I don't know why more extensions don't use it.

Customising browser interface is possible with userChrome.css on Firefox, and there's something similar for Vivaldi but it's actually supported. I'm not sure if anyone has bothered releasing a Vim add-on for it though.

Can you write a simple script using native messaging to launch the current URL in mpv? The api looks much too complicated for me to figure it out myself.

I'm on my phone so this is untested:

`composite js document.location.href | !s mpv`

Should work. I think we might have a `currenturl` ex command that you could replace the js bit with but I can't remember.

> hoping to read a compiled list of obscure inconveniences that have prevented you from using alternative browsers.

I've tried all of the previous lightweight vim-like incarnations of the webkit2-lib based browsers. Not being much of a browser customisations person beyond adblocking my issues were solely with the inadiquate browser engine "webkit2" which was ultimately abandoned, it was always slow to be updated, increadibly slow and insecure.

This is why I thought qutebrowser was worth a post on HN, because it's the first of these lightweight keyboard driven type browsers that I have found with a completely useable modern up-to-date engine behind it (QTWebEngine[1]):

    Relationship to Chromium
    
    Qt WebEngine uses code from the Chromium project. However, it is not containing
    all of Chrome/Chromium:
    
    - Binary files are stripped out
    - Auxiliary services that talk to Google platforms are stripped out
    - The codebase is modularized to allow use of system libraries like OpenSSL
    
    We do update to the latest Chromium version in use before a Qt release. After a
    release some bug fixes and security patches are backported. For LTS releases of
    Qt we might also update Chromium in a patch level release.

This is why it basically feels like using chrome, because it's essentially the same core engine.

I've not used qutebrowser extensively enough yet to comment much on the front-end, but the most important part is there, the nice engine without any nasty privacy violating services built in. But my first impressions with the front end are pretty good, and i'm not even a vim user.

[1] https://wiki.qt.io/QtWebEngine

To be fair, WebKit2 isn't abandoned (WebKit1 was, and some projects never migrated to WebKit2) - at least in WebKitGTK+ (which most projects use), that's still maintained: https://webkitgtk.org/

However, QtWebEngine is probably still ahead of WebKit, both security- (sandboxing) and feature-wise.

To me, the show stopper was web pages blinking white when reloading or opening a new tab. And no real way to fix that, except to change the global CSS, which messes up some websites that doesn't set background-color, etc. etc.

A few reasons off the top of my head.

I'm a big fan of surf for example, but it leaves it up to the users to implement features like history, which I never got around to doing. Sure, someone's probably already posted his implementation for that, but nonetheless the sad pragmatics of not investing the time into that eventually helped drive me towards the bloated, but featureful point and click browsers. To be clear, I'm completely in favor of this kind of modularity in systems, but at the same time the tinkering is a two edge sword, if I had found a good premade surf setup to fork, then I would have been left with only the positive aspects, I guess.

Another example, which is a bit more serious, is that these projects seemed to be chronically out-of-date, or not fully compatible with my systems, because I'd have some rendering or interaction problems from time to time.

Which kind of brings me to my next point. Web, the platform, sucks. It's complex and bloated. It suffers from the system within a system syndrome. That's why it keeps moving. By consequence, the browsers have to not only be complex as well, but also keep moving equally fast. The big browsers just have a large advantage in situations like this.

the main reason i dont use it is the hints work differently from pentadactyl. you cannot type characters of the link and have to use the letters that appear on the hint. so i'm still on pale moon+pentadactyl. but i think qutebrowser has great potential.

Have you tried out the new tridactyl[0] webextension?

[0]: https://github.com/tridactyl/tridactyl

i have. in addition to not launching on startup, it seems to have this same issue. i like that in pentadactyl i can just start typing out the text of a link. or use a number. so im not a fan, but it can work if you insist on a major browser.

Vimium has this option. Check the box on the options screen " Use the link's name and characters for link-hint filtering"

Thanks for the tip! Probably makes more sense than typing random characters.

You can if you do :set hints mode number.

Is that documented somewhere? I can’t find it on their website, but searching on mobile means the issue is just as likely to be me as the documentation.

:help hints.mode

http://qutebrowser.org/doc/help/settings.html#hints.mode

oh. thanks. thats great. but...now i have a graphical issue where the command line falls off the screen.

Wonder how this runs on old hardware. I have a 2009 dual core laptop with 4 GB of RAM that runs everything I throw at it without a problem, except a web browser. Web browsers are just too heavy. My solution is to use Textadept, with Lynx as a backend, as my "browser" on that machine. Works well (can even open YouTube videos in VLC) but I miss having a real browser.

I have pretty much the same type of machine, and while it's true browsers are hevier than they used to be, I suspect it's the rest of the software on your machine consuming too many resources to leave anything for the browser... With my x session and window manager my machine only uses about 300MiB RAM, browsing is not unlike using a modern machine.

If you are using a big DE consider switching to something lighter and you might be surprised how little RAM you can use.

(My anecdote is from using both Chromium, FireFox and qutebrowser more recently - I haven't noticed much performance difference in the latter but it wasn't struggling to beggin with)

QtWebEngine, like CEF and other Chromium lib distributions, doesn't come with proprietary video/audio codecs compiled in. This is for obvious legal distribution reasons and can be compiled by the user manually. I hope as more browser downloads come about without proprietary codecs, more websites start providing formats like webm.

It does if you install qtwebengine from the sources of most distributions (eg: debian, ubuntu). The one from pip does not come with it though, which the win/mac releases are compiled with.

Used this regularly for a couple of years but stopped at some point, had it as my default browser for opening links but it never became my main browser, mainly because it didn’t integrate with password managers and some things didn’t quite work. Haven’t used it for a good year and a half now so it might have improved.

You may want to try some of the password filling userscripts available. The best support is for pass, but theres userscripts for lastpass and keepass too.

https://github.com/qutebrowser/qutebrowser/blob/master/misc/...

The word userscript makes me think that it injects js onto the page? If that's the case, couldn't existing js hijack that? Sounds unsafe.

It looks like they're written in python.

Not necessarily - any language which can read environment variables and write into a file should work. Most existing scripts are using either Python or Bash though.

Qutebrowser userscripts aren't in-page JavaScript at all. They're external scripts run by the browser to control its behaviour.

http://qutebrowser.org/doc/userscripts.html

Yeah, the name is a bit unfortunate - it's coming from dwb[1] which I think also invented that concept, and was the main inspiration for qutebrowser.

[1] https://portix.bitbucket.io/dwb/

Interesting, might give it a try again.

See passmenu (pass) or passhole (KeePass) for password autotypers that work with any program.

Disclaimer: I wrote passhole.

https://github.com/cdown/passmenu

https://github.com/purduelug/passhole

Used this on Debian testing a year ago or so, worked quite well. I think I didn't get it to properly run on Ubuntu 16.04 for some reason, maybe time to reevaluate.

One can never have too many browser to separate tasks out, although Firefox containers are a solid replacement oftentimes.

You won't be able to use the Qt version in the repos for Ubuntu 16.04, but if you're on x86_64, you can use a prebuilt PyQt which ships with Qt: https://github.com/qutebrowser/qutebrowser/blob/master/doc/i...

I would really like to use this as my primary browser, unfortunately Atlassian's login flow doesn't work in this browser. I suspect it is actually Atlassian at fault here but since I am forced to use Jira for work I have no choice.

Can you try setting "content.cookies.accept" to "all" instead of the default "no-3rdparty"? If that doesn't help, can you set with --temp-basedir?

I'm impressed by how readable the code is. I also miss dwb, I just haven't had time to re-adjust to the keybindings.

Still not sure whether it was a good idea to (mostly) copy dwb's keybindings - some of them are a bit weird and inconsistent...

Installed qutebrowser last week. Can definitely recommend it!

Used it for awhile then had it stop working for certain needs. Switched over to palemoon and pentadactyl. Happier with that combo.

Palemoon is forever stuck with a version of Firefox that is older, less secure, and slower that going forward will be incapable of taking their project forward or even finding and plugging security holes.

Also they assert the right to decide how bsd/linux distributions package their work on pain of lawsuit.

https://github.com/jasperla/openbsd-wip/issues/86

Their behavior was tactless and poorly considered. I wouldn't trust them to make me a ham sandwich let alone maintain my browser.

Just install tridactyl which is about feature complete compared to pentadactyl by now.

That issue was... Insane.

Toxic behaviour, misunderstandings of how BSD works, and no interest in working with people doing the hard work for Palemoon.

They demand their own patched versions get included with their browser... With no consideration that they may not even run on BSD.

it is a regrettable episode but they had their reasons. i would also wish this would not be used against this great project. everyone knows how territorial we can be as developers. people make mistakes.

i have been using it and pentadactyl ever since vimperator stopped working and i love it. it gets updated frequently and fairly recently had a rebase to a newer ff build. also their theming support is really nice and their logo isnt as obtrusive. give it a chance and you won't regret it.

Why would I not regret moving from Firefox 64 to a version based on a several year old version thats less responsive. Its like your Ford pintos awesome stereo wouldn't work with a car with abs and airbags so you drive a decades old pinto. There are good stereos that don't involve driving a pinto.

Funny thing about old cars: You can work on them. I actually drive a 97 Ford and also have a 97 Camry. What good is a fancy stereo if the car sits in the driveway because you can't work on it?

The anology kind of breaks down when both browsers are free open source.

It's unfortunately not the only questionable decision taken by the Pale Moon devs - see e.g. https://www.neowin.net/forum/topic/1363542-pale-moon-team-di...

In my experience, this decision is correct. Noscript does cause the browser to bog down and do all manner of annoying things that causes instability.

As a project lead, you get to decide things like what goes in the project or leaves. Not everything needs a discussion once it has been decided.

I suspect the "not allowed to be discussed" is implemented so that these discussions are bypassed and those that don't like the decision can simply vote with their feet.

Whatever their ideologies are, palemoon simply worked for me, and qutebrowser did not. At some point, especially with a computer, functionality is going to win over ideologies.

I will say that I understand the need to try to keep control of one's projects and what others do with them. See the recent linux mess for details.

As a vimperator user still on 52 ESR, this sounds great but any serious browsing requires me to use my add-ons, umatrix, ublock origin etc. Do we extensions work on this?

Actually on second thoughts extensions probably don't have a relationship with layout engine but with browser GUI so maybe no.

No WebExtension support, and unless Qt implements support for them, I'm not sure that'll change: https://github.com/qutebrowser/qutebrowser/issues/30

However, there's a built-in adblocker (which only blacklists hosts right now), and there are plans for something like uMatrix: https://github.com/qutebrowser/qutebrowser/issues/28

Url changed from https://github.com/qutebrowser/qutebrowser to the project page, which seems like the canonical URL for this project.

Could you change the title please? The project is called "qutebrowser". No dash and no capitalization.

Will two thirds do? It's a convention to keep the first letter of an HN title capitalized.

Sounds good to me. Thanks!

No, it's a Chromium browser skin that uses Qt.

I think you are wrong, given that it is based on Webkit components. In what way does it use Chromium code?

You're both a bit wrong. It can use either QTWebKit or QTWebEngine at runtime. The latter is the default and is essentially the engine of chromium extracted from chromium without any google services or binary blobs (uses system libraries)... this is quite far from a chromium skin, it's not a fork of chromium, and it lacks more than the front end, it completely removes all of the privacy invasive features that has been troubling everyone recently.

This info on QTWebEngine is among the top comments on the page if you care to look.

It's not - QtWebEngine strips a lot of Chromiums sources (like the entire UI, and things like Google sign-in code) out.

Reply on news.ycombinator.com