So, we made it in time for the release. After months of hard work 2.28 is out, and hopefully it will hit a repository near you (in case you are not so much into hunting projects in their natural habitat). Some reviews think Ephy/WebKit is not too bad and appreciate the effort we are putting into bringing WebKit into the platform, so I guess we can be happy of our progress so far.
Speaking of WebKit, we branched for our semi-stable 1.1.15 release. After some talks we decided to not declare our APIs stable yet, since the development is still advancing very fast and we could use a full cycle of testing to see what works and what doesn’t, but nevertheless we will support 1.1.15.x as a stable release in every other aspect: no new features, only bugfixes and patches for security issues, supported until the next stable release is out. It’s the recommended companion for GNOME 2.28, so distro guys you know what to do! And, just to see if anyone was paying attention, we quickly rolled a 18.104.22.168 with a couple of important bugfixes; you can get it at the usual place.
2.30 – The Future
But enough talk about the past, what will the future bring? These are some of the things that we plan to do, or at least get started, for 2.30.
GObject DOM bindings
WebKitGTK+ already provides APIs to do most of the things applications need to do when dealing with Web widgets, with one very big exception: access to the DOM. DOM manipulation has to be done, as of today, through sad APIs like webkit_web_view_execute_script, which make doing anything other than trivial things pretty cumbersome and difficult to debug. Wouldn’t it be nice to be able to access the page contents through nice GObject APIs, with bindings for all languages through gobject-introspection? Yes, it would, and it clearly is what we are missing to be able to create a new kind of GNOME applications. Other ports, like Mac or Qt, already provide something like this, so clearly we have to step up to this challenge Expect to see, at least, basic GObject DOM bindings for WebKitGTK+ in time for GNOME 2.30.
GNOME shell integration
An idea that has been floating in my head since GCDS is to try to integrate Epiphany more closely in the coming brave new world of GNOME Shell. I think our UI can be kept simple and usable and at the same time updated to use all that crap the chip manufacturers have been putting into your computer for the past 10 years, so we should give that a shot. I’ll be attending the Boston Summit to see what I can do about this being among all the Shell gang, and rumour has it Gustavo is already doing some crazy experiments with Clutter and Epiphany.
When WebKitGTK+ was accepted for 2.28 the Release Team expressed their trust in that we’d continue our work improving the a11y support in the engine. Me and Igalia will keep our commitment to see this happen, and with 2.28 behind us I’m already looking into it again. Also, I’ll finally meet Joanmarie during the Boston Summit, which I’m sure will be serve to make things move faster and better.
HarfBuzz font backend
Behdad speaks, and we listen. In his own words the Pango backends in WebKitGTK+ and Gecko are either hacks or have to reimplement lots of things that they shouldn’t have, and the right thing to do is to go down one step in the stack and use HarfBuzz directly. This is also a good opportunity to get rid of our multiplicity of font backends, so expect some HarfBuzz love in WebKitGTK+ in the coming months.
Improved HTML5 media support
The final assault on the Flash empire is about to start, and we want to be ready. We already have support for it, but the WebKitGTK+ team (with a new Igalian, Philippe), is already busy fixing all the bugs and implementing all the missing features.
A lot is on the pipeline for the tasty library. As I mentioned in previous entries, during the 2.27 development cycle Dan realized some of the things we were trying to bolt on on the library would be much easier if some of its internals were revamped, so he put in motion a bold plan to address this. With that in place, a couple of our biggest regressions (HTTP cache and Content-Encoding support) should be easier to kill.
The bugs! The regressions!
Yes, yes, that too! Be sure to report all of them.