About WebKit, browsers and mail clients. And green cats.

Menu

Post navigation

Our new session management nicknamed tabby need a little bit more polish so we decided to go for a double length release cycle. This is a proper rewrite of the tab loading at startup and for the first time fully aware of multiple windows, able to load most recently used websites first and smart enough to not block GUI updates. If that’s not impressive enough it designed to get a sync backend and session management GUI is already work in progress, though it’s not ready for the spot light yet.

We also made the switch from WAF to cmake. What does this mean to end users? Nothin much. But to developers and contributors it means a lot. A big motivation was frustration from package maintainers with several aspects of WAF such as compatibility and the need to ship a binary blob. And in fact most contributors never got the hang of it. cmake on the other hand seems to win people over for not so obvious reasons. It’s in many ways tailored towards doing what it does while giving decent error behavior.

We also went with GApplication aka GLib.Application. No more choice between Unique and our own custom sockets implementation, which means less bugs due to different code paths and code possibly being disabled in some builds. It’s notably not Gtk.Application because we’re still crazy enough to support GTK+2 on its last breath which mainly means no use of new features that didn’t exist before either.

As always see the file Changelog for more details. And stick around for a bit if your package isn’t there yet, it can take a while.

Upgrading time for our Windows build. While all of these are pretty much under-the-hood changes it has a big impact on your browsing experience. We’re going for the latest stable WebKit with JIT-enabled javascript and WebP support. And we’re switching to a more recent maintained set of GStreamer plugins – in the past these weren’t easily available and always required extra work to add.

See below for the technical overview and currently known issues. The build still needs some rigorous testing to move from experimental to stable – if it works well it will be used for the next Midori version.

Build details

WebkitGtk 2.0.4

Spellcheck (you need to install dicts yourself for now)

JIT for javascript enabled

WebP support

GStreamer 1.0 plugins

Known Issues

Dark shadow on inactive buttons (gtk3 style issue)

Cursor does not change appearance on links/ textarreas (webkitgtk3 issue)

As I posted earlier I organized the first proper Midori booth for FrOSCon. From my humble perspective it was a success despite the rainy weather. All sorts of different folks who’d never heard about it got curious about Midori when they walked by the booth, asked what it is and what makes it special. A number of people asked about specific bug reports or availability on distributions. And among them some very interesting feature discussions came up.

Session management was a recurring point of interest. Opening many tabs and windows, managing multiple sessions, storing away sessions for later and restoring after a crash. This is a good time as Tabby, the new session backend, is about to land, and it will make it much easier to keep many sessions or throw away the last open tabs on startup. One point in particular I’d like to take away here is that restoring tabs is something to be decided after startup, or after a crash instead of a fixed preference as it is now.

Another hot topic was sync. Firefox Sync appears to be quite popular for being easy to setup on a server. In one case the university provides logins to students as part of their infrastructure, which encrypts all session data. A very nice solution I would be keen to see is pluggable backends. Besides Firefox Sync there’re plans for a Midori sync server based on PGP encryption.

As for the booth itself, it appears that stickers were popular. But apart from the poster we had nothing with the URL written on it to hand out. Definitely for the next Midori we will need business cards. Overall it was very exciting and I am looking forward to the next event in November.One thing different kinds of people asked about is writing extensions. I saw some eyes flashing when I mentioned that using Python will soon be possible, besides Vala and C, thanks to libpeas. The API in general will become easier to use and we brainstormed a bit for a third party extension website.

My humble self has been helping with Geany and Xfce booths in the past. Though I originally left the organisational aspects to somebody else I got accustomed to the process. So I figured why not go the whole way. There’s one more person besides me by the looks of it and we’re going to wear these fancy t-shirts you see in the picture. Anyone who’s attending FrOSCon feel free to stop by on the 24th and 25th of August, in Sankt Augustin, it’s easy enough to find and there’s other reasons besides Midori to come!

Time for a Midori 0.5.5 with a whole lot of exciting changes. Let’s have a look together at some of the highlights:

The proxy server support received improvement. Hostname prefetching is automatically disabled when a proxy is in use which plugs a potential privacy leak and the way we hook into the global proxy server settings is using offical API now, which should make it more robust.

Another improvement happened in the cookie department. Since a new enough libSoup is required we’re now sharing the cookie jar implementation (no pun here, that is its technical name). Our maximum cookie age code got much more robust, so when you set eg. 1 Week no cookie will survive longer than that even if a website tries to re-create it within that time (anyone interested in the gory details may use MIDORI_DEBUG=cookies to monitor it).

The context menu was in large parts rewritten. The code re-using built-in default menus from the time before WebKit had a sensible API is gone. It was a source for many buglets. At the same time it just got so much easier to extend context menus in Midori extensions.

The web app (and profile) support received more polish and got better integrated.

For WebKit2 we still have a long way to go, truth be told. But we’re making progress. It is at this point at the bare minimum of browsing the web, though still many small details are missing, not all icons show up, many extensions still don’t work. Anyone interested here will find this is a great area to get involved.

And…drums rolling the NoJS extension is here in all its glory. It surely is one of the most-requested features, which allows you to take control of scripts on a per-domain basis. It’s opt-in or opt-out depending on your personal preference.

The next release is incidentally going to be a 4/ 2 cycle with 4 weeks of features and 2 weeks of freeze, or bug fixes in other words. The pattern has worked very well and we’re not abandoning it but it may be beneficial to have more time to focus solely on existing bugs.

Error pages are looking quite a bit nicer now and also try to be more informative. Alexander popped out of nowhere to work on it and other little improvements to the speed dial.

Bookmarks are also improving at an increasing pace thanks to André. Several bigger changes are already in the pipeline for the next cycle.

Another worthy highlight are the increased minimum requirements. Glib 2.23.3, GTK+ 2.24, Vala 0.16.0 and WebKit 1.8.3 are required now. If you wonder why that’s good news consider the large chunks of backwards compatibility code we were able to drop, which paved the way for improving thumbnail generation and favicon handling among other things.

Judging by what the duck says Midori must be the only project in the world migrating from git to bzr. Or maybe, it was just so surprisingly quick and simple that there’s no need to brag about it. In fact Launchpad itself performed the import automagically and the switch is really about updating documentation and a cuple of hyperlinks. It might’ve been harder if I wasn’t familiar with bzr yet; pushing the new trunk and flipping an option to make it the focus branch was all that was needed.

The old world

Why did we actually make this step? To make project management more efficient. Midori as a project roughly might be split into

bug triaging

reviewing contributions

implementing code

design decisions

roadmap

It turns out a huge bottle neck was the manual effort standing between these separate aspects. For example anyone doing bug triaging wouldn’t have direct access to code. And code review was always separate from both code and bug management. To the point that people end up waiting on, looking for and blocking on each other. And losing contributors, which is the worst thing to happen to any free software project.

The new world

There’s an obvious, easy way for anyone to push branches

Code review is integrated with branches and bugs

Anyone can become a reviewer, merge and push code

bzr vs. git

I do enjoy a proper emotional project bashing as much as the next guy, especially with a beer in front of me. But really, these days bzr and git both have a comparable share, personally I work on either one on and off. And at the end of the day what counts is the health of Midori as a project. Bazaar may well have the weaker storage efficiency and performance compared to git in a benchmark, but in this case git had the higher human cost.

With a slightly prolongued freeze period Midori 0.5.1 0.5.2 is out of the door. We made a big leap on the promised WebKit2 support – it’s not fully done yet but very, very usable despite not having context menus and some extensions are to be done. Definitely worth giving a go for anyone curious about multi-process goodness who can live without adblock if need be.

Downloads and web app support have both received major refactoring, making the code much more modular and approachable, and fixing buglets and adding polish along the way. Downloads work more reliably across windows and more quality control across panel and toolbar. The way is paved for even more goodness. For the first time you can manage web apps/ launchers created from within Midori graphically. This is also up for even more improvements.

To round it up a whole lot of code improvements have come from static analysis such as clang (LLVM) and other sources and a number of buglets were squashed. Despite all the bigger changes QA is looking very good. Note to self: having strict feature freeze periods before every release is paying off, even if it’s hard in a small team.

Update: I apparently goofed up the release process and 0.5.1 insists it is still 0.5.0. To reduce confusion this is 0.5.2 now, same thing, but with a proper version.