Since the Epiphany migration to WebKit, websites with an invalid SSL certificate were marked as untrusted with the unsecure lock icon in the location bar. However, it wasn’t possible to know what was wrong with the certificate nor the certificate details. Using the certificate viewer widget available in gcr, I’ve implemented a dialog to show information about the possible SSL errors and certificate details in Epiphany. This also means Epiphany now depends on gcr.
During the last week, the Igalia WebKit team has been working on adding the initial support for WebKit2 into Epiphany git master. As we did for Devhelp, there’s a configure option (–with-webkit2) that can be used to build Epiphany with WebKit2. The option is disabled by default for now. The WebKit2 GTK+ API is more and more mature and complete, but there are still some important features to implement in order to be able to enable WebKit2 by default in Epiphany. Nevertheless, the main functionality works already and we encourage everybody to give it a try and provide feedback and bug reports. You can also take a look at the Epiphany metabug or the WebKit2 GTK+ API roadmap if you want to help.
The plan is still to have a first stable version of WebKit2 GTK+ API for GNOME 3.6, but Epiphany will switch to WebKit2 by default when we manage to fix all the regressions, hopefully for GNOME 3.8.
The GNOME Project has released GNOME 3.4, the second major release of GNOME 3. A lot of new features, UI improvements and other enhancements are included in this release, as well as important changes in the development platform. You can see all the details in the release notes.
One of the applications that has received a major revamp is Epiphany, the GNOME Web Browser, not only because of the beautiful new interface, but it also has significant improvements in performance and stability. If Epiphany is not your default browser, give it a try when you upgrade to GNOME 3.4. See Xan‘s and Diego‘s blog posts for more details of the new Web Browser.
GNOME 3.4 includes WebKitGTK+ 1.8.0, the first stable release that contains an initial WebKit2 GTK+ API. It’s disabled by default, though, since it’s still a preliminary version, so you need to build with –enable-webkit2 configure option. It’s already possible to try it out with Devhelp 3.4 which can be optionally built with WebKit2 using –with-webkit2 configure option. If the current API is enough to port your application, give it a try and let us know, you can use the webkit2 devhelp branch as a reference. We’ll provide a migration guide soon too.
GTK+ 3.4 has finally support for kinetic scrolling in GtkScrolledWindow. I’m very happy to know that the work made by Igalia during the GTK+/Meego Handset integration project has helped Carlos Garnacho to properly integrate kinetic scrolling in GTK+.
That’s the plan! But, what’s exactly WebKitGTK+ 2.0? It will be the first stable release of WebKit2 GTK+ API, leaving the current WebKit GTK+ API in a maintenance mode. WebKit2 GTK+ is not just about multi-process architecture, robustness, stability and all other great things the new WebKit2 model brings, it’s also a redesign of the current WebKitGTK API to make it even more convenient and easier to use.
In the Igalia WebKit team, we have planned a Roadmap of the tasks we will be actively working on to release WebKitGTK+ 2.0 for GNOME 3.6. Even though unit tests play a very important role in the WebKit2 GTK+ API development, we know that real applications using the API usually reveal issues that the unit tests or test programs like MiniBrowser don’t catch. For that reason, we have set milestones consisting of porting real applications to the new API.
- GNOME 3.4: Applications using a small part of the API. We will focus on porting Devhelp.
- GNOME 3.5: With the first unstable releases of the 3.5 cycle we should be able to port applications using the API more extensively. We will focus on porting Yelp.
- GNOME 3.6: We should be able to port any application using WebKitGTK+ without major regressions. We will focus on porting Epiphany.
This is, of course, a plan, if we eventually don’t manage to achieve the milestones, we will release WebKitGTK+ 1.10 for GNOME 3.6 and current plan will be postponed to GNOME 3.8. Needless to say that any help would be more than welcome
When MiniBrowser was ported to the new WebKit2 GTK+ API, I said we had plans to create a webkit2 branch for epiphany. And we’ll do it as soon as we have enough API, but epiphany uses most of the WebKit API so this is going to take a bit. In the meantime, we have decided to focus on other applications that use a small part of the WebKit API like devhelp, yelp, liferea, etc. Yesterday I pushed a webkit2 branch into the devhelp git repository with some initial commits that allow to use devhelp with WebKit2. Even though WebKit2 is available in the latest WebKit unstable releases, there’s a bug and public headers are not installed, so you need to build WebKit from git to be able to build the devhelp webkit2 branch. The main functionality works, but there are still some features missing that we are currently working on:
- Policy client: used by devhelp to decide what to do with unknown content and to open links in a new tab with middle click. Martin Robinson is working on Policy Client API for WebKit2, the patches are pretty good and will be pushed soon.
- Search: We already agreed on the new API and Sergio Villar wrote the patch that will also land soon.
- Printing: This is not only about adding API, it requires adding support for printing in the Web process too. The main problem is that we need to show the print dialog in the UI process and render pages for printing in the Web process, so we can’t use GtkPrintOperation. We have already patches to implement basic printing support and adding initial API. These patches only work for UNIX, so patches to make it work in win32 would be really appreciated.
- Editing commands: There’s already a patch to add cut, copy and paste API, but we are discussing the possibility to move to a more generic approach for editing commands.
And here is the mandatory screenshot, although there’s nothing special since WebKit2 changes don’t affect the UI.
We will keep updating the webkit2 branch when new API lands in WebKit until there aren’t regressions. Then we’ll focus on yelp which requires two important challenges: DOM bindings and context menu API.
We have just released WebKitGTK+ 1.7.3, the first release that includes WebKit2 API docs already generated in the tarball. The documentation is also available online now. Take into account that WebKit2 is still under development and the API might change, more specifically WebKitWebLoaderClient is going to be removed soon.
More than a month ago I released libgxps 0.1.0, the first release of libgxps, but for several reasons I ended up not announcing it. I’ve just released a new version that includes a small API break and a lot of new features and improvements, see the release notes for further details. I’ll release evince 3.3.2 next week depending on this new libgxps version (when building with –enable-xps).
MiniBrowser is a small web browser application for testing WebKit2. MiniBrowser for the GTK+ port has been working for some time now, but it was implemented using the C-based WebKit2 API. WebKitGTK+ 1.7.1 introduced an initial high level GTK+ API for WebKit2 more similar to the current WebKit1 GTK+ API. This week, Igalia‘s WebKit team started to port the MiniBrowser code to use the new GTK+ API.
This new GTK+ API is far from complete compared to the WebKit1 API, but it’s already possible to implement a small application with basic features, and we have plans to create a webkit2 branch for epiphany soon. API is already documented in the code, but the html generation is not available yet. We are already working on it so that WebKitGTK+ 1.7.2 will generate the API documentation when compiled with –enable-gtk-doc and –enable-webkit2 and it will be available on the WebKitGTK+ website too.
Thanks to the multiprocess architecture, WebKit2GTK+ solves the problem of using flash (or any other plugin using GTK+2) with GTK+3. The UI process depends unconditonally on GTK+3 and the plugin process is always built with GTK+2. And of course, flash will never crash or block your web browser. Plugins are broken in WebKitGTK+ 1.7.1 due to a bug that has already been fixed, so in order to try it out you need to either wait until 1.7.2 is released or build WebKit from current git master.
|MiniBrowser showing a youtube video|
When GNOME 3.0 was released some weeks ago, I finally switched to gnome-shell by default. Performance is quite good in my laptop, so the only problem was getting used to the new user experience. After several weeks using it, there are only a few things I really miss:
- Real launchers: I use a lot of gnome terminals, and when I click on the gnome-terminal launcher I really want a new terminal.
- Window list applet: ALT+TAB is a mess when you have several gnome terminal windows because all thumbnails look pretty similar. Window list applet allowed you to see all your windows in the current workspace and select any of them by a single click. It’s true that window list applet buttons don’t help to identify your terminal windows either, but you can reorder them and I usually identify a terminal window by its position in the panel.
- Workspace switcher applet: similar to window list applet, I want to be able see all my workspaces and swtich to any of them by a single click. I always use the same workspace for the same kind of activity (mail, web browsing, devel, irc, im), so it’s very annoying when a workspace dissapears just because I’ve removed all the windows.
I still don’t have a workaround for all my use cases, but I’ve managed to make my life a bit easier by using a gnome-panel inside the shell. The only thing I had to change in gnome-panel was the D-Bus service name. And here is the result:
|GNOME Panel running with GNOME Shell|
GtkScrolledWindow: kinetic scrolling
The first time I tried to use the press-and-hold patch to allow selections and drag and drop operations in GtkScrolledWindow when kinetic mode is enabled, it didn’t work because press-and-hold patch uses some of the signals (motion event) consumed by GtkScrolledWindow using the captured-event. So, I thought I could make it work by using the captured-event for the press-and-hold implementation too. I reworked the press-and-hold patch to use the capured-event and the scrolled window patch to use the press-and-hold signal, and it indeed worked!