Keeping qutebrowser up and running

All 6 months, a new Qt feature release is published. Other upgrades (like Python itself) also need attention from time to time.

Testing new Qt versions early means that I can report bugs upstream during the Alpha/Beta phase, which means they'll likely get fixed before a release. Often, adjustments to qutebrowser itself are also needed to keep it running smoothly when distributions upgrade their Qt versions.

In the past few weeks, I spent quite some time dealing with Qt 5.13.1/.2, Qt 5.14 and Python 3.8.

A change coming with PyQt 5.14 currently causes trouble with a piece of qutebrowser (the object registry) which I wanted to remove for a while now. I started working on that as well recently, but there's more refactoring work needed to complete the removal.

In 2020, Python 2 will (finally!) be retired, but qutebrowser still uses asciidoc for its documentation, which is unmaintained and based on Python 2. I intend to switch to Sphinx instead, which should also make it easier to write (more) nice documentation for qutebrowser.

Getting the pull request backlog down

Since I had barely enough time to keep things running smoothly during my studies, a backlog of contributions accumulated.

There are various new features, bugfixes, performance improvements and a lot of other great work to find there.

I find reviewing code to be something that takes more concentrated focus than writing code, so I can't review PRs all day (I tried!). However, I plan to spend some time on the PR backlog regularily to get things back to normal again.

Extension API

I want to continue work on the extension API in order to get something released which is generally available and usable.

Much of the work on the extension API also ties into the next point - there's a lot of refactoring needed to get (sometimes quite old) code into a shape where it is reasonably nice to expose via an extension API.

I'm aware this is taking a lot longer than originally anticipated. However, I'd like to avoid exposing code where I anticipate major changes/restructurings - otherwise, every qutebrowser upgrade would break a lot of extensions every time.

Increasing maintainability

This means reducing technical debt, improving the testsuite (getting it to run faster and more stable) and introducing mypy / type hints across the codebase.

In the past few weeks, I added type hints to various qutebrowser modules and got mypy running with the --check-untyped-defs flag. That flag tells mypy to check the bodies of functions which are not type annotated yet, which uncovered a few subtle bugs and will make upcoming refactorings a lot easier.

Second look at the config system

The new configuration system (introduced in the 2017 crowdfunding) works quite well - especially compared to the old one. However, some design decisions in it cause various performance issues. I have some ideas how to change those internals to make things faster and simpler. In the past few months, contributors (especially @jgkamat) have worked on various performance improvements, but I believe a bigger impact would be possible by changing how qutebrowser stores configuration data internally.

tl;dr

• Keeping things running smoothly
• Taking care of open contributions
• Working on the extension API and at the same time refactoring various areas
• Making configuration internals faster and simpler

I'm excited to see what's to come and how the fundraising turns out. Feedback very welcome!

-- Florian / @The-Compiler