If you’re wondering what browser engine this is running (as I did), it appears to be using WebKit: https://next.atlas.engineer/article/technical-design.org
More importantly, they have gone to some effort to isolate the browser engine from the UI so that it is possible to swap out browser engines without rewriting the whole browser. Interesting project!
Next also supports Webengine (a Blink fork, the Chrome engine) through the PyQt port.
Edit: Note that the “technical-design” article is somewhat outdated. For instance, XML-RPC has been replaced by D-Bus.
Could somebody write a gui wrapper for next browser fairly easy? Like if I wanted to add a gnome header with a menu listing buffers is there an api for hooking into that functionality from an external program?
For the former, this is just about extending Next. We have plans to add a status bar, possbly buttons, a configuration page, etc.
For the latter, for now you can use the Swank protocol to send arbitrary Common Lisp to Next (and thus query anything). I’m soon planning to add a commnad line --eval option so that anyone can do it, even if they don’t speak Swank.
I may have misread the design document. I was under the idea that Next was embeddable. So one could embed the browser in a gui (like neovim) and interact with it through rpc or dbus calls. This way somebody could write a ui that conforms to gnome or kde HIG.
With regards to the clarification, will there be a gui extension api or will the extensions have to go upstream and get merged?
The thing is that the browser and the GUI are the same thing here.
What communicates over D-Bus is just the web renderer (e.g. WebKit). Common Lisp does everything else, including manipulating the minibuffer, creating buttons, etc.