Fiber is DEAD! Long live Fiber!

So, over on G+ I had it pointed out to me that my multi-process work was… Pointless. It really kinda killed Fiber as it was. Apparently WebEngine covered the bases I was running at. While it was super-sad to see my work circle down the toilet bowl (along with my ‘hacker cred’!) it was also a bit of a relief; not only do I get it for free, but it would have been done better and more robustly than I could have.

The main thing it changed was the fact that anything I would do from that point forward could either be pulled or applied to existing browsers, raising the question; should I fork, contribute, or still start from scratch? I knew I had 3 goals;

  • Deep KDE technology integration.
  • Present a polished, stable, modern experience.
  • Be simple by default, powerful when needed.

And a few ‘key’ features;

  • Be Multi-process CLEAR!
  • Extensions over hardcoded features
  • Custom per-tab profiles

I looked to see what was around, and there are 4 browsers which I could work with;


Qupzilla isn’t KDE-specific, and I their thing is cross-platform. I very specifically want to target a KDE-oriented browser. Additionally it’s still on Qt4, I want a Frameworks 5 oriented browser. Apparently they’re on Qt5!

Even with the Qt5 version, I’d still be taking an uncomfortable number of liberties with their goals. Also, the plan seems to be a QML-based browser – Qupzilla is out.


Rekonq is currently ~the~ KDE browser, it has the fullest KDE integration, and is established.

The major downside is the fact that Rekonq is an inactive project; it has been stagnant for over a year. Additionally, despite being a browser based on KDE tech, Firefox has supplanted it as the default browser on even the most vanilla distributions.

I’ve been looking at the code and there are some worrying mistakes; I won’t pick it apart, but I spotted a few things that concerned me. Additionally, like QupZilla, it’s still on Qt4 and needs to be ported to Frameworks 5.

Generally, I feel Rekonq has a large amount of baggage; it needs to be ported to Qt5, it has some outstanding issues, and it seems the developers have lost interest… Rekonq is out.

QT Demo Browser

QT Demo Browser is what Rekonq was based off long ago. Since it’s just a demo, basing off it would be a new project; but it is Qt5, and the most ‘vanilla’ of the bunch.

Qt Demo is, well, a demonstration. It has valuable up-to-date code, and is somewhat no-frills. But, because it’s just a demo it also lacks many subtle features that make modern browsing pleasant. It’s also built like a traditional application, so it has a structure that looks more like IE6 than a modern browser.

Qt Nano Browser

Qt Nano Browser is a QML-based browser. It has the absolute fewest features, and is no-nonsense in its quest to simply present a QML-based tabbed browser.

The downside is, the thing really is a skeleton, and there’s a huge amount of basic functionality missing. Compared to the other browser, the question is whether or not I want to strip something down, or build something up.

The Plan

The plan is to start a new browser from scratch (or, re-start), as I was going to previously. I’m currently in a debate between traditional widgets or a QML driven UI.

I should go QtQuick, as it has some clear advantages and is another differentiating factor vs contemporary widget-based browsers. If I do so, I’ll instead base of QtNanoBrowser or at least refer to the nano browser. About the only reason I’m debating QML is because we had an agreement to disagree, but I should really just accept it and drink the juice.

So, as it was (my little multi-process experiment) is dead! But the time and effort that will be saved will go into creating something richer, different, and modern.


9 thoughts on “Fiber is DEAD! Long live Fiber!

  1. I really I hope you’ll come to grips with QtQuick eventually. It may still suck a bit, but if we want Plasma to run on different form factors, we desperately need a browser which does so as well.
    We had a browser in Plasma Active and it was nice UI-wise, but it was still based on QML 1 and QtWebkit, and we all know this only gets you so far.


    1. I think I’ve come around to the QtQuick juice; I’ve been thinking about it carefully and I’m really strongly agreeing with your points that you’ve made. I may have some rough edges initially, but I’ll get there.

      I don’t know if this is “feature-creepy” or not, but now that the big “multi-process” feature seems to be taken care of, I may try to make “multiple form factors” a priority if I can do it.


      1. I don’t think you’d have to do the versions for different form factors yourself. As long as you create the basis for them by a clear separation between logic and UI, others can take up the UIs for the other form factors.

        Creating a decent browser with an extension system even for one form factor is hard enough for a single dev as it is 😉


      2. I’ve done some research on this topic not long ago, so here’s my 42 cents.

        I think in general, the idea of going with QtQuick is fine. It allows for pretty flexible interfaces, and encourages a good separation of logic and UI, which makes it easy to do different interfaces for devices at some point.

        Once you have a look at the QML bindings for QWebEngine, however, the picture is more sobering. You can do some very basic stuff with it, but as soon as you want to implement some features you’d expect from a basic browser, they’re pretty much impossible with what’s in the bindings currently, and from its design, it also doesn’t seem very straightforward to add them to the bindings. Here’s a selection of things I didn’t find solutions for:

        – Encryption status of the page, is it loaded via HTTPS, if so, which elements, which certificate, etc? Absolutely zero support AFAICS
        – Filtering of requests for adblock for example, for this you’d want to use your own QNetworkAccessManager (like Rekonq does), yet no way to get at that functionality
        – Access to specific elements of a page, to save an image, for example, no API
        – You don’t get access to QWebElements, QWebFrame, QWebPage and all their friends through the QML bindings

        Then, leading the list of more general problems:
        – No support for ARM currently, it doesn’t build, I tried to make it build and it left wanting to poke my eyes out with a rusty device made of metal.
        – Deployment is one huge question mark, QtWebEngine’s source repo has 3rd party directories inside 3rd party directories (I’m not kidding you!), some distros have already indicated that this is not acceptable due to distribution policies and for the sake of security support, the discussion is ongoing without a clear solution so far.

        There’s more, but I think this list above already means that the QML bindings shipped with QWebEngine and QWebEngine itself is not a no-brainer when it comes to which renderer to use.


        1. I was acutely aware that webEngine QML bindings were still unfortunately immature, but the solutions aren’t as bad as you might initially think. The plan is to have only skeletal components be burned into the browser, limited to the core address bar, tab bar, menu button/menu bar, and status hud. All other buttons would be QML or API based and provided by extensions. Because of my extension plan, I’ll be providing my own API for QML components to interact with the browser. This means I have two roads for a (mostly) QML-based browser;

          A. Make the chrome of the browser QML, including the main UI and the status hud, then make the webview alone a standard widget. I don’t need to worry about direct QML bindings as much because I’ll be providing an extension API through the browser.

          B. Make the entire skeleton of the UI traditionally, and extensions would remain QML-based. Since nearly all widgets presented to the user would be extension-based, this will leave very little chrome to QWidgets, which would more/less only provide scaffolding.

          I’m doing my homework right now on which way I’ll be going with this. I have things worked out in terms of how I want these extensions assembled, and both options are viable. I’m leaning towards option A because it will be the more flexible of the two. I’m not concerned about QML components having direct access to the WebEngine, because it will all be abstracted behind the extension API, and I’m going to try making everything extension-based.


  2. have you looked for Otter?

    it could be a good project to start from (QT5, simple by default, etc)… the only differenze in tour vision is Otter prefers features over extensions


    1. I looked at Otter a while ago when I was browser hunting. And I don’t think on a personal level I’m interested in contributing or forking it. The main reason is because I have a bit of a philosophical issue with trying to make ‘clone’ software, and Otter wants to be an Opera 12 clone.

      I won’t be contributing to it because I think it limits the potential of a project when the leads give the road an “end point”. Once they’ve duplicated Opera 12 there will be nothing to do, no evolution, no growth, no improvement. Everything they’ll build will always be in the service of a fixed point, and what may have been good at one time may not always be optimal. Just at an awareness level I also find ‘clone software’ has issues, especially the way Otter is doing it can mean having a really hard time establishing a unique identity. The name Otter, the O logo, the UI, it’s all in service of Opera.

      I wouldn’t fork it either, I think my goals are to divergent from where they are now. I want a QML base, and a focus on running features as removable extensions, so I would probably spend most of my time decoupling features.


      1. Otter like to share a common code base, they already offer the Qupzilla dev that kind of cooperation:

        This means: Use a completly different UI for your browser, Otter seems to be designed for that aim. 🙂

        By the way: You write in another blog post, that HTML can replace QML in further releases, is that completly disestablished ?

        There is still a qupzilla / only qt4 line in your text here: “Additionally, like QupZilla, it’s still on Qt4 and needs to be ported to Frameworks 5.” (In the Rekonq section.)

        Please, come and chat in #otter-browser on freenode, in order to join forces and make it more easy for everyone of us.

        Nice day 😀


        1. By the way: Otter ships a lot of very unique features, which are not present in ANY browser: that includes the old Opera of course as well. Multiple Backends, as an example: Otter is build to work with different backends, you can even switch between them while the Browser is up and running. you can have even one tab with QtWebKit and another one with QtWebEngine in parallel and its easy to implement Gecko, Servo and others. This may make sense to you, since you are/was undecided about the Engine in Fiber.

          Otter aims to recreate the UI of the old Opera Browser: No word about the “Opera Features” on the Webpage.

          Emdek will implement much more features as the old Opera ever ship.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s