Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
There should be support for writing plugins which are more complex than the simple (non-js) userscripts. Python plugins are the way to go.
What's the current state of this issue?
October 2019: See the recent roadmap mail for more details on what's going on in qutebrowser development - this definitely isn't forgotten, there are just some more important things to look at first. I also launched the next crowdfunding which will allow me to work on qutebrowser part-time (without having to write a research paper this time
How can I get updates?
Subscribe to this issue. You might also want to subscribe to the qutebrowser-plugins repository and the qutebrowser-hsr-sa repository where the related university documentation will land (also check the releases if you're curious).
Support for WebExtensions is currently out-of-scope for qutebrowser. It's hard to even evaluate to which extend support for them would be possible, but if possible, it's going to be a lot of work. Partial support for often used plugin APIs (i.e. some WebExtensions) might happen some day, but currently it's too early to say if/when. The main focus is on a Python plugin API right now. Related QtWebEngine issues which might make this easier: QTBUG-51185, QTBUG-61676.
Also, a Python plugin API will allow for more freedom, since we treat plugins as trusted code.
Why don't you just allow people to inject Python code into qutebrowser?
Firefox had the issue of having a plugin API which tightly integrates with its internals, and had to drop it because it made further Firefox development harder, and bigger changes impossible. Also, every Firefox update broke a lot of plugins. This is not what I want things to end up like with qutebrowser.
In theory, you can do some things via a
Do you call them plugins or extensions?
They used to be called plugins - however, since that term is often used to refer to NPAPI/PPAPI plugins (like Flash) in the context of web browsers, they were later renamed to extensions.
Abilities that plugins should have
Possible API inspirations
Other interesting links
Separate namespace for plugins
There should be a new
Only some stuff (like possibly
If something is missing from the wrappers, it should be trivial for a plugin author to open a feature request to have it added - this should be encouraged in the docs.
Qt signal based workflow
I don't think using something like pluggy will be neccessary (especially because pluggy is still expected to undergo changes, and is not packaged).
Instead of that, there's a simple function (say,
Those events/signals are the main entry point for plugins. There will also be APIs for certain tasks (like adding an icon to the statusbar), but the majority of tasks should be possible using those signals.
For most actions, an API to call commands nicely (i.e. as functions rather than as strings) would probably already suffice.
Exposing plugin signals to userscripts
This could possibly be implemented as a plugin by itself, which binds to all available signals - some layer to transform the signal arguments to strings will be needed either way.
A line written to the FIFO could look like this:
I'm not usually in favor of shutting down discussions, as people who follow qutebrowser development might know - however, after talking to some other contributors, I'm now locking this issue.
I just went through the ~80 comments here again, and condensed everything that has been said into the first post (including a small FAQ) or into related issues. There was a lot of reappearing discussion which was already discussed earlier in the issue, and frankly, I'm tired of people acting like I owe them a plugin API ASAP (hint: there's a difference between "Please" and "PLEASE").
The best way to get updates about work on the plugin API is to subscribe to this issue, same like with other issues. Comments which aren't actually related to how the plugin API should look just mean dozens (hundreds?) of people interested in this issue get yet another mail - kind of defeating the purpose of subscribing to it to get updates.
If you have something useful to contribute which isn't mentioned in any of the still visible comments, feel free to reach out via other means, and I'll update the comments with further ideas.
I just posted a roadmap mail to the announcement mailinglist - here's the gist of it related to extensions:
The research project went quite well (paper), but also was quite academic - not that much time was actually spent on implementation. As a result, there's now an initial extension API used internally in qutebrowser, but it's far from finished and not open to third-party extensions yet.
I likely won't have much time to continue working on extensions until my bachelor thesis is finished in mid-June (see the announcement mail for details), but after that I plan to launch another crowdfunding focused on long-term donations (Patreon/OpenCollective). This should allow me to work 2-3 days per week on qutebrowser for a longer time, primarly focused on finishing extensions.
I just added an update: See this announcement mail for a longer recap of how the research project went. I finished my Bachelor thesis and had my final exams in late August. This means my studies are now finished and I finally have more time for qutebrowser on my hands again. Like outlined in that announcement mail, I'm now employed around 16h/week, while I plan to spend the rest of the time on qutebrowser and some freelancing work. At the moment, I'm planning the next crowdfunding campaign (also see the related survey) and getting things set up. After things are rolling, there are some things which are currently more urgent than plugin support: Making sure things continue to work with the latest Qt 5.13/5.14 versions and taking care of a lot of contributions. Once that backlog is down and some other work I started is finished, I finally plan to get back to extension support again, this time with enough resources to get things to a working state!
See the recent roadmap mail for more details on what's going on in qutebrowser development - this definitely isn't forgotten, there are just some more important things to look at first. I also launched the next crowdfunding which will allow me to work on qutebrowser part-time (without having to write a research paper this time