[qutebrowser] Happy 9th birthday, qutebrowser!

Kai Zhang iamtoogad at gmail.com
Thu Dec 15 15:54:02 CET 2022


Thank you so much! Qutebrowser is my default browser!


On Wed, Dec 14, 2022 at 14:25 Florian Bruhin via qutebrowser <
qutebrowser at lists.qutebrowser.org> wrote:

> Hey!
>
> full version of this post with links on Reddit or GitHub Discussions:
>
> https://www.reddit.com/r/qutebrowser/comments/zm0x5c/happy_9th_birthday_qutebrowser/
> https://github.com/qutebrowser/qutebrowser/discussions/7526
>
> qutebrowser is turning 9 today! I’ll use the opportunity for a – perhaps
> slightly tl;dr – overview of how it all came to be. As you might notice
> by the length of this post, stopping to write once I started writing
> something like this… isn’t exactly my forte! Hopefully the wall of text
> will be interesting nevertheless :).
>
> The death of dwb
>
> Back in 2013, I was a happy user of dwb, but it became apparent that the
> project would die at some point. It was clear that dwb would need to
> make the switch to WebKit2, but the author (portix) didn’t have the
> bandwidth to do so – as far as I remember, they said it’d basically be a
> full rewrite, and it’s not going to happen.
>
> While dwb lived on for another 3 years or so, many dwb users – including
> me – were looking for alternatives. There were things like uzbl or
> luakit, and addons like Vimperator, but for some reason or another,
> those just didn’t fit the bill.
>
> Back then, WebKit – especially WebKit 1, still used by most of those
> projects – was plagued by frequent hangs and crashes (and it being a
> single-process model, a renderer crash meant that your whole browser did
> go down with it).
>
> A new browser on the horizon
>
> I toyed with the idea of taking over dwb maintenance – however, it was a
> C/GTK codebase. While I was writing microcontroller firmware for a
> living in C for a couple of years, it always seemed an odd choice to me
> for more OOP-like GUI programming. With projects like Wireshark or LXDE
> wanting to switch to Qt at the time, it also became clear that GTK
> wasn’t what I wanted things to be based on. The only real alternative to
> build a web browser was Qt (Electron was only 5 months old!).
>
> With plans about a new Chromium-based QtWebEngine already on the
> horizon, this seemed like a great choice. In terms of programming
> language, the choice was between Python and C++. C++ is the “native” Qt
> language, and Python bindings have been around since 1998 (!) and were
> maintained very well. Anything else was out of the question pretty much.
> Since I had some more Python knowledge than C++ knowledge, and C++ is…
> quite a beast, I decided to go with Python.
>
> And thus, with thoughts along the lines of “eh, there are good libraries
> for it, how hard can it be?”, exactly 9 years ago today, I started
> qutebrowser.
>
> It initially was focused on dwb “refugees”, and much of that is still
> visible today: The look of the UI, almost all keybindings, the split
> between book- and quickmarks (probably a bad idea), the idea of having
> external userscripts (probably a bad name), etc. etc. In other areas,
> qutebrowser most likely had a pioneering role: As far as I know, it was
> the first vim-like browser to introduce a more shell-like command
> interface, with things like :open -t or :open -w rather than separate
> :open, :winopen and :tabopen commands. Others like Tridactyl later
> followed suit.
>
> Towards the first release, and then some more
>
> It took a lot of work until, exactly a year later, v0.1 was finally
> released. Later, Vimperator died with Firefox dropping XUL extensions,
> and between 2014 and 2019 or so, more and more people switched to
> qutebrowser (up to around 10% of all Archlinux users participating in
> package statistics).
>
> More recently, I was able to work on qutebrowser during my study summer
> break in 2016, again in 2018, and finally for a longer time as a
> part-time job since 2019. I’m humbled by all the support, it’s what
> still keeps me going – it’s fair to say that I probably would have
> burned out and/or stopped by now if I was employed 100% still. Turns
> out, after all, a web browser isn’t exactly an easy thing to do as your
> first big open source project. Big kudos to all the other projects which
> have been going for years if not decades: It’s not easy, and the
> occasional entitled user who’s pushy or angry at you for their favourite
> feature™ still not being implemented certainly does not help.
> Thankfully, those cases are rare: All in all, I’m thankful for the
> qutebrowser community being so understanding, patient and helpful! <3
>
> Another big transition
>
> It’s probably fair to say that dwb died during the transition from
> WebKit 1 to 2. Such major upgrades – while often reasonable and needed –
> tend to use a lot of energy and effort.
>
> In 2016, qutebrowser had its own first big migration, when QtWebEngine
> finally was ready enough to add support for it. Nowadays, QtWebKit is
> still supported, though mostly for historical reasons. Chances are big
> it will be all gone for the v3.0.0 release.
>
> Nowadays, qutebrowser is in a somewhat similar big transition again: It
> desperately needs to migrate to Qt 6 to keep things up to date, but –
> while not quite a rewrite – doing so is a bunch of work. With
> qutebrowser getting older, more popular, and also getting lots and lots
> more contributions (often in slighly chaotic ways, as things go with
> open source), this transition is probably the most challenging of them
> all yet! There are many more things to take into consideration than
> there have been six years ago. Still, much of it has been going on ever
> since Qt 6.2 with QtWebEngine was released in September 2021, with a
> branch with almost 300 commits being nearly finished. If you haven’t
> yet, you should probably give it a try!
>
> Looking forward towards qutebrowser v3
>
> There are still some challenges to overcome on the development side of
> things, and some other stuff I’d like to at least look at for the v3.0.0
> release. Last year, my job situation changed as well: Instead of being
> employed 40% over the entire year (often taking a lot more energy and
> mind-space than those 40%), I’m now busy teaching between September and
> February. On the flip-side of the coin, that means I don’t have anything
> other than open source (qutebrowser, pytest, and the occasional paid
> pytest company training) to worry about between March and August. Last
> year has shown that this works out much better, especially for big
> chunks of work like this.
>
> Even though things are still very busy dayjob-wise now (and will be
> until March), I’m hoping we can still work on some of the remaining Qt 6
> blockers, and then I’m hoping to still be able to finish v3.0 early next
> year. Thanks also to everyone who keeps the ball rolling while I might
> be busy with other stuff for a while – especially @toofar, who has been
> doing amazing and steady work over the last couple of years!
>
> Onwards, and already looking forward to qutebrowser being a decade old
> in late 2023!
>
> Florian
>
>
> --
>             me at the-compiler.org | https://www.qutebrowser.org
>        https://bruhin.software/ |
> https://github.com/sponsors/The-Compiler/
>        GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
>              I love long mails! | https://email.is-not-s.ms/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20221215/0320c8e1/attachment.htm>


More information about the qutebrowser mailing list