Catfish 1.0.2 Released

I’m happy to announce that Catfish 1.0.2 has been released.  Find out what’s new in this release!

What’s New?

I thought the delay in previous release announcements was embarrassing… but there have been several stable releases since my last post (0.6.1).  I’ll try to keep this brief.

New Features

  • Switch to toggle standard and preview modes
  • Search filter for directories

General Improvements

  • Full Python3 support
  • Improved locale and encoding support
  • Updated to support the latest PyGObject APIs (minimum 3.6)
  • Introduced SudoDialog to handle user authentication (shared with Mugshot)
  • Code cleanup, removed unused template code, improved installer
  • Improved list logic with item selection
  • Interface refresh, mimicking common gnome applications
  • Improved handling of symbolic icons
  • Improved strings

Bug Fixes

Screenshots

Catfish with the latest Greybird theme. Catfish with the latest Numix theme. Catfish with the latest Ambiance theme.

Getting Catfish

Ubuntu Users

If you’re running Ubuntu 12.10 or 13.10, Catfish 1.0.2 is available from the Catfish Stable PPA.

sudo add-apt-repository ppa:catfish-search/catfish-stable
sudo apt-get update
sudo apt-get install catfish

If you’re running Ubuntu 14.04 or newer, Catfish 1.0.2 is available in the Ubuntu repositories.

sudo apt-get install catfish

Everyone Else

If you’re running another Linux distribution, you can download the latest source package from the Catfish downloads page.

Advertisements and two little kittens

Today is the day of Midori 0.5.8. Dedicated to Adblock and WebKit2. Rather than trying to meet fixed dates as we used to, we selected which goals define if the cycle is done. No more no less.

As liked, fast and efficient our Adblock extension was, the original maintainer isn’t around anymore and flaws were accumulating on a code base that wasn’t very accessible anymore. So long story short Adblock is rewritten from C to Vala, several classes and files instead of one monolithic entity, plenty unit test cases and real whitelist support. Add to that a statusbar icon for easy flipping filtering on and off and seeing whether anything was blocked on the site. If you had problems with peculiar display problems whilst using Adblock, chances are good they’ll be gone with the upgrade. Adblock is as always shipped with Midori so just be sure to enable it in the Preferences!

In other news WebKit2 is making another big jump and closer to the finish line. Text selection behavior, favicons, support for multiple rendering processes, opening new windows and setting cache and cookie paths correctly. There’s still work to do in the areas of extensions and downloads in particular, but we’re getting there.

We have working spelling corrections again. Right-click an underlined word and pick a suggestion from the menu. It’s that simple.

Two new extensions implement Ctrl+Enter to complete www. and .com and a handy little notes panel which automatically saves one or more snippets as you make changes.

Aaaaaand we’ve got a brand new file type editor (MIME type on Linux). Finally the user is in control of how files open, either via the Preferences or the right-click “Open With…” menu item.

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.

So download Midori v0.5.8 now (1.2 MB)

Some downloads are still being refreshed right now, so be patient if you think the option of your choice isn’t there yet.

You are welcome to join #midori on irc.freenode.net and party for the release!

WebKitGTK+ 2.4.0: the multiprocess made easy

Yes, we did it again, we have just released WebKitGTK+ 2.4.0, another major stable release with a lot of bug fixes, some new features and more complete API.

Multiple Web Processes

This is the most important new feature included in this release, and the one we have spent most of the release cycle with. All started during the WebKitGTK+ hackfest when a team of around 10 people worked together to implement the base of the multi-process support. And at the very end of the release cycle we have been able to turn it on by default in Epiphany.

DOM touch events support

WebKitWebView now processes the touch events happening in the widget to notify the DOM, making modern websites using DOM touch API properly work. Carlos Garnacho has taken a screencast to show it in action

Plugins cache

When the first page containing plugins was loaded, the UI process got blocked for some time, while the plugins were scanned. This was one of the most annoying bugs of WebKitGTK+ introduced in 2.0. Plugins are synchronously scanned on demand during the page load, and it’s something that can’t be avoided. WebKitGTK+ 2.4 uses a persistent cache to store information about all plugins, so that plugins are only scanned the first time or when they change.

New API

As always a huge thanks to all the contributors that make this possible, and very specially in this release to the sponsors of the WebKitGTK+ hackfest 2013 (Igalia and the GNOME Foundation).

WebKit1 deprecation

There’s one last thing I would like to mention. Even when WebKit1 API has been deprecated since we released WebKitGTK+ 2.0, we have kept shipping both APIs in our tarball releases. A decision hasn’t been made yet, but this is probably the last release including the WebKit1 API, we have plans to remove the WebKit1 code from trunk and move all the build bots to run only WebKit2 tests. We encourage everybody to port their applications to WebKit2, submitting bug reports if there’s anything preventing the switch, and of course we are happy to help on IRC, mailing list, etc.

Peas and Beans

The avid user may have noticed the release is overdue, although scheduling a release over new year’s eve was probably a lost bet to begin with, so that’s why. The good news is we got some extra bug fixing time.

So what did we get done? A good amount of clean-up including a revamped notebook – this is tech jargon for the tabs UI – with the goal of reducing bugs due to different build configuration, regardless of whether one is using GTK+2, GTK+3, Granite or Windows. A good deal of dead code could be dropped and many things simplified. There’s also a new Database abstraction which you don’t see on the outside but improves error handling and reduces bugs by unifying how things are done.

Now this is all nice and boring, are there any actual changes? Yes! Session management, nicknamed tabby, again gets smarter about reacting to crashes by not loading the faulty website and running commands on the command line properly. Private browsing has also benefited from some bug fixing, such as not wrongly attempting to load favicons from disk and enabling the sidepanel, for example for downloads (or other panels from extensions, for the brave ones who use the command line to enable extensions in private browsing).

Oddly enough one very small feature we got which I find amazingly useful myself ever since it’s there: Close Tabs to the Right. You wouldn’t think it does much, but if you’re applying a workflow of search and open as many results tabs as you can, and suddenly find all but one very much obsolete, this is exactly what you need.

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.

So download Midori v0.5.7 now (1.2 MB)

Some downloads are still being refreshed right now, so be patient if you think the option of your choice isn’t there yet.

You are welcome to join #midori on irc.freenode.net and party for the release!

Windows snapshot build for the upcoming 0.5.7

The current experimental build has had mostly positive feedback so it will be the basis for the upcoming Midori 0.5.7 for Windows. As described in detail earlier WebKit and GStreamer were updated. This also contains the latest featureset from trunk which is entering freeze now. This includes refactored tabs, better font defaults, and a number of smaller fixes. Any testing now can help findings bugs before the next release!

Known Issues

  • Dark shadow on inactive buttons (gtk3 style issue)
  • Cursor does not change appearance on links/ textarreas (webkitgtk3 issue)
  • Slow load when font cache is missing (fontconfig issue)

Grab the experimental Windows build now and help testing! User feedback is valuable, either in comments, bug reports or #midori on Freenode (webchat).

WebKitGTK+ Hackfest 2013: The Network Process

As every year many ideas came up during the WebKitGTK+ hackfest presentation, but this time there was one we all were very excited about, the multiple web processes support. Apple developers already implemented the support for multiple web processes in WebKit, which is mostly cross platform, but it requires the network process support to properly work (we need a common network process where cookies, HTTP cache, etc are shared for all web processes in the same web context). Soup based WebKit ports don’t implement the network process yet, so the goal of the hackfest became to complete the network process implementation previously started by EFL and Nix guys, as a first step to enable the multiple web processes support. Around 10 people were working on this goal during the whole hackfest, meeting from time to time to track the status of the tasks and assigning new ones.

After all this awesome work we managed to have the basic support, with MiniBrowser perfectly rendering pages and allowing navigation using the network process. But as expected, there were some bugs and missing features, so I ran the WebKit2 unit tests and we took failing tests to investigate why they were failing and how to fix them.

So, we are actually far from having a complete and stable network process support, but it’s a huge step forward. The good news is that once we have network process implemented, the multiple web processes support will work automatically just by selecting the multiple web process model.

All this sounds like a lot of work done, but that’s only a small part of what has happened this week in Coruña:

  • Martin and Gustavo made more parts of WebKit actually build with the cmake build.
  • Jon made several improvements in Epiphany UI.
  • Gustavo fixed the default charset encoding used by Epiphany.
  • Iago, Edu made some progress in the wayland support for WebKit2.
  • Dan was working on HTTP2 implementation for libsoup.
  • Zan was finalizing his GSoC work under Martin’s mentorship to bring WebGL support under Wayland
  • Gustavo added support for right-side docking of the web inspector in WebKitGTK+.
  • Javi, Rego and Minhea were focused on a new implementation for the selections in CSS regions.
  • Calvaris began to rewrite the GTK media controls once more, this time in JavaScript.
  • Zan finished the patches to add battery support in WebKitGTK+ using upower.
  • Martin, Gustavo and Zan worked on support for testing WebGL and accelerated compositing layout tests in WebKitGTK+.
  • Brian, Alex and Zan were working on the parsing of the valgrind xml output used when running the tests under valgrind to detect memory leaks.
  • Brendan added a setting to both WebKit1 and WebKit2 APIs to enable media source and fixed a crash in several video layout tests.
  • Claudio went back to his work on the notifications support for WebKitGTK+ and was reviewing patches like crazy.
  • Philippe worked on the WebRTC implementation for the GStreamer WebKit media backend.
  • Mario, Joanie and API were focused on accessibility, also making sure that the multiple web processes doesn’t affect the accessibility support.
  • Brendan also worked on MediaSource, investigating how to handle video resolution changes.
  • I removed all the WebKit1 unused code from Epiphany, and moved the GNOME shell search provider to its own binary.

And I’m sure I’m missing more great stuff done that I could not follow closely. It’s definitely been a very productive hackfest that it would haven’t been possible without the sponsors, Igalia and the GNOME Foundation. Thanks!

Igalia S.L. GNOME Foundation

Two WebKittens

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.

So download Midori v0.5.6 now (1.2 MB)

Some downloads are still being refreshed right now, so be patient if you think the option of your choice isn’t there yet.

You are welcome to join #midori on irc.freenode.net and party for the release!

Midori on OpenRheinRuhr in Oberhausen November 9/ 10

Looking back at a very successful presence in St.Augustin the preparations for OpenRheinRuhr are already underway. I just got definitive confirmation of the booth. People asked about t-shirts, and having checked that the organizers are okay with it I’m going to make some available at the booth.

Anyone interested in helping out in Oberhausen on November 9/ 10 is welcome, just poke me (kalikiana) in #midori on Freenode or drop me an email.

WebKitGTK+ 2.2.0: It shines and doesn’t blink

With a bit of delay but we have finally released a new stable version of WebKitGTK+. This is the first stable release after the major 2.0 release. It mainly contains a lot of bug fixes and a few important new futures and API additions.

New Web Inspector

WebKitGTK+ now uses the new Web Inspector recently opensourced and upstreamed by Apple. We took advantage of the migration to improve the way inspector resources are distributed by compiling them in the WebKitGTK+ library as GResources. This means that resources are now always available without having to run make install or set environment variables.

WebKitGTK+ new Web Inspector

Initial Wayland support

WebKitGTK+ 2.2 can be built with Wayland target if it’s available (it requires GTK+ 3.10 compiled with Wayland support). Not everything is fully supported yet, but the WebKit layout tests can be run under the Weston compositor and WebGL content works under Wayland displays too. There’s more detailed information in Žan Doberšek’s blog.

Video accelerated compositing support

When accelerated compositing is enabled, the GStreamer media player can play videos using OpenGL. You can find more details in Víctor’s blog.

Custom JavaScript injection

This was one of the major regressions in WebKit2GTK+ compared to the WebKit1 API. WebKitGTK+ 2.2 now allows to inject custom JavaScript code using the JavaScriptCore C API from a WebKit Web Process Extension. New API has been added to also allow running specific JavaScript code in isolated worlds. You can find examples about how to use this API and how to write Web Process Extensions in general in this post.

Improved accessibility support in WebKit2

Accessibility support in WebKit2 has been reworked to not depend on pango and gail, which resulted in several bugs fixed and a much better accessibility support. Check Mario’s blog for all the details.

New API

WebKit2GTK+ Web Process Extensions

The multiprocess architecture of WebKit2 brought us a lot of advantages, but it also introduced important challenges, like how to expose some features that now live in the Web Process (DOM, JavaScript, etc.). The UI process API is fully asynchronous to make sure the UI is never blocked, but some APIs like the DOM bindings are synchronous by design. To expose those features that live in the Web Process, WebKit2GTK+ provides a Web Extensions mechanism. A Web Extension is like a plugin for the Web Process, that is loaded at start up, similar to a GTK module or gio extension, but that runs in the Web Process. WebKit2GTK+ exposes a simple low level API that at the moment provides access to three main features:

  • GObject DOM bindings: The exactly same API used in WebKit1 is available in WebKit2.
  • WebKitWebPage::send-request signal: It allows to change any request before it is sent to the server, or even simply prevent it from being sent.
  • Custom JavaScript injection: It provides a signal, equivalent to WebKitWebView::window-object-cleared in WebKit1, to inject custom JavaScript using the JavaScriptCore API. (Since 2.2)

This simple API doesn’t provide any way of communication with the UI Process, so that the user can use any IPC mechanism without interfering with the internal WebKit IPC traffic. Epiphany currently installs a Web Extension to implement some of its features such us pre-filled forms, ads blocker or Do Not Track using D-BUS for the communication between the Web Extension and the UI Process.

How to write a Web Extension?

Web Extensions are shared libraries loaded at run time by the Web Process, so they don’t have a main function, but they have an entry point called by the WebProcess right after the extension is loaded. The initialization function must be called webkit_web_extension_initialize() and it receives a WebKitWebExtension object as parameter. It should also be public, so make sure to use the G_MODULE_EXPORT macro. This is the function to initialize the Web Extension and can be used, for example, to be notified when a web page is created.

static void
web_page_created_callback (WebKitWebExtension *extension,
                           WebKitWebPage      *web_page,
                           gpointer            user_data)
{
    g_print ("Page %d created for %s\n", 
             webkit_web_page_get_id (web_page),
             webkit_web_page_get_uri (web_page));
}

G_MODULE_EXPORT void
webkit_web_extension_initialize (WebKitWebExtension *extension)
{
    g_signal_connect (extension, "page-created", 
                      G_CALLBACK (web_page_created_callback), 
                      NULL);
}

This would be a minimal Web Extension, it does nothing yet, but it can be compiled and loaded so let’s see how to create a Makefile.am file to build the extension.

webextension_LTLIBRARIES = libmyappwebextension.la
webextensiondir = $(libdir)/MyApp/web-extension
libmyappwebextension_la_SOURCES = my-app-web-extension.c
libmyappwebextension_la_CFLAGS = $(WEB_EXTENSION_CFLAGS)
libmyappwebextension_la_LIBADD = $(WEB_EXTENSION_LIBS)
libmyappwebextension_la_LDFLAGS = -module -avoid-version -no-undefined

The extension will be installed in $(libdir)/MyApp/web-extension so we need to tell WebKit where to find web extensions before the Web Process is spawned. Call webkit_web_context_set_web_extensions_directory() as soon as possible in your application, before any other WebKit call to make sure it’s called before a Web Process is launched. You can create a preprocessor macro in the Makefile.am to pass the value of the Web Extensions directory.

myapp_CPPFLAGS = -DMYAPP_WEB_EXTENSIONS_DIR=\""$(libdir)/MyApp/web-extension"\"

And then in the code

webkit_web_context_set_web_extensions_directory (webkit_web_context_get_default (), 
                                                 MYAPP_WEB_EXTENSIONS_DIR);

The Web Extension only needs WebKit2GTK+ to build, so in the configure.ac you can define WEB_EXTENSION_CFLAGS and WEB_EXTENSION_LIBS using pkg-config macros.

PKG_CHECK_MODULES(WEB_EXTENSION, [webkit2gtk-3.0 >= 2.0.0])
AC_SUBST(WEB_EXTENSION_CFLAGS)
AC_SUBST(WEB_EXTENSION_LIBS)

This should be enough. You should be able to build and install the Web Extension with you program and see the printf message every time a page is created. But that’s a useless example, let’s see how to use the Web Extensions API to do something useful.

Accessing the DOM

The GObject DOM bindings API available in WebKit1 is also exposed in WebKit2 from the Web Extensions API. We only need to call webkit_web_page_get_dom_document() to get the WebKitDOMDocument of the given web page.

static void
web_page_created_callback (WebKitWebExtension *extension,
                           WebKitWebPage      *web_page,
                           gpointer            user_data)
{
    WebKitDOMDocument *document;
    gchar             *title;

    document = webkit_web_page_get_dom_document (web_page);
    title = webkit_dom_document_get_title (document);
    g_print ("Page %d created for %s with title %s\n", 
             webkit_web_page_get_id (web_page),
             webkit_web_page_get_uri (web_page),
             title);
    g_free (title);
}

Using WebKitWebPage::send-request signal

Using the Web Extensions API it’s possible to modify the request of any resource before it’s sent to the server, adding HTTP headers or modifying the URI. You can also make WebKit ignore a request, for example to block resources depending on the URI, by simply connecting to the signal and returning TRUE.

static gboolean
web_page_send_request (WebKitWebPage     *web_page,
                       WebKitURIRequest  *request,
                       WebKitURIResponse *redirected_response,
                       gpointer           user_data)
{
    const char *request_uri;
    const char *page_uri;

    request_uri = webkit_uri_request_get_uri (request);
    page_uri = webkit_web_page_get_uri (web_page);

    return uri_is_an_advertisement (request_uri, page_uri);
}

static void
web_page_created_callback (WebKitWebExtension *extension,
                           WebKitWebPage      *web_page,
                           gpointer            user_data)
{
    g_signal_connect_object (web_page, "send-request",
                             G_CALLBACK (web_page_send_request),
                             NULL, 0);
}

Extending JavaScript

Using the JavaScriptCore API it’s possible to inject custom JavaScript code by connecting to the window-object-cleared signal of the default WebKitScriptWorld. You can get the global JavaScript execution context by calling webkit_frame_get_javascript_context_for_script_world() for the WebKitFrame passed as parameter of the window-object-cleared signal.

static void 
window_object_cleared_callback (WebKitScriptWorld *world, 
                                WebKitWebPage     *web_page, 
                                WebKitFrame       *frame, 
                                gpointer           user_data)
{
    JSGlobalContextRef jsContext;
    JSObjectRef        globalObject;

    jsContext = webkit_frame_get_javascript_context_for_script_world (frame, world);
    globalObject = JSContextGetGlobalObject (jsContext);

    /* Use JSC API to add the JavaScript code you want */
}

G_MODULE_EXPORT void
webkit_web_extension_initialize (WebKitWebExtension *extension)
{
    g_signal_connect (webkit_script_world_get_default (), 
                      "window-object-cleared", 
                      G_CALLBACK (window_object_cleared_callback), 
                      NULL);
}