As someone who spent quite a lot of time getting QtWebKit built and kept up-to-date on Mer, both for Qt 4.8 and 5.x, I'm somewhat torn to see this: > We heard at the launch event that the rendering engine is Gecko On one hand, I feel a little sad. On the other hand, I can appreciate the idea of going with a browser engine that isn't as big a political playing field as WebKit. (Or its Google-fork: Blink.) The reasons…
Interesting. I remember that Meego went back and forth between WebKit and Gecko, but that was a long time ago, I would also be interested to hear how things ended up that way.
I know at least one very good reason, from personal pain.
Meego preceded Qt 5.0. QtWebKit was not part of official Qt releases until 5.1, and in 4.x the situation was even worse. Back then QtWebKit was always a second-class citizen. The browser engine was a separate "Qt component". This meant that all releases were done individually, outside and out of pace with the Qt proper. Any release lagged behind the Qt releases, taking anywhere from weeks to months to catch up and work with the most recent Qt release. I got the idea that the webkit team was severely undermanned and overworked.
This meant that for any product that wanted to use QtWebKit, the product manager had to make an early decision to lock the version of used Qt just to ensure that QtWebKit was available. (Customers demanded a working browser engine with bells and whistles.) So from a purely practical point of view it made sense to decouple the browser engine and Qt release at architectural level.
No wonder Meego hovered between the two options. They had the choice of not using the latest Qt releases but having a more finely integrated browser engine - or they could go with the latest Qt, a decoupled browser engine and doing a horrible amount of additional integration work to keep Qt and Gecko in sync.
As one can imagine, neither of those options is particularly appealing.