There’s a lot to talk about, so let’s get started.

WebKit2

For the first time in this release, Web uses by default the all new multi-process architecture known as WebKit2. The advantages of such a design are well known by most, but here is a brief list of what this means for us:

• Stability: we now run all the WebKit code in a different process (WebProcess) than the UI code (UIProcess). Most crashes, by far, happen inside WebKit, so this will make the application a lot more stable. When crashes happen, you’ll get a message explaining how to continue browsing, just a reload away. Note that for 3.8 we run all the web pages in the same WebProcess, just like Safari for OSX did in 5.1, but we plan to move to multiple WebProcesses in the near future.
• Responsiveness: not only most crashes happen inside WebKit, but most of your CPU (and GPU!) time will generally also be spent there. By moving this processing away we allow the UI to be always ready to react to your input, so tab switching and scrolling are now super smooth. You’ll have to see it to believe it, but trust me when I say the improvement is enormous.
• Plugins: in WebKit2 plugins run in their own process (PluginProcess). In general this makes the browser more robust against the frequent crashes and hiccups of some plugins, but for GNOME in particular it means something even better. Flash, as our more loyal users know well, has not worked natively in Web since we switched to GTK+3. The Adobe plugin is stuck in GTK+2, and since using both libraries at the same time in one process is forbidden we have been forced to rely on things like nspluginwrapper for a while. Well, not anymore: we compile our PluginProcess with GTK+2 precisely for this reason, so Flash works again out of the box.
• Security: finally, by isolating all the web content from the application we reduce the possibility of malicious code having access to sensitive information. This will be greatly enhanced in the future with the sandboxing of the WebProcess, but 3.8 lays the first stone for a safer browsing.

Our WebKit2 port and Web backend have been more or less in continuous development for more than 2 years. This is the result of a lot of hard work by all the WebKit contributors, the Igalia WebKit team and the Web developers. Despite being a collective effort, like most free software, I want to thank Carlos García Campos in particular for leading the WebKit2GTK+ effort with so much energy. His hard work and perseverance were instrumental in making this happen, so the usual beverages or thank you notes are more than deserved next time you see him.

All this would be more than enough for a single release, but there is much more to see. Let’s keep going.

Private browsing

As advanced during the last WebKitGTK+ hackfest, Web 3.8 brings a straightforward way of launching a temporary and private browsing session, free from any data that could possibly identify you, that will leave no trace on the hard drive once you are done with it. Just go to the application menu and click “New Incognito Window”, you are all set.

Undo close tab

You closed a tab just to realize you actually needed to check one more thing in there. You pressed the wrong key. Selected the wrong menu item. Nevermind, in 3.8 Web will remember the tabs (and windows!) you have recently closed, and bringing them back to live is as easy as pressing Ctrl-Shift-T or selecting “Reopen Closed Tab” in the application menu.

UI polish

You want a shiny new search bar? We have it:

A handy new tab button in the main toolbar? Got it:

Vastly improved Web App icons and titles? Yep:

Fancy HTML5 media controls perhaps? You bet:

Plus less clutter in the gear menu, improved theming, simplified Preferences dialog, and many more small UI tweaks.

3.10 and beyond

As usual we are already working on the next major release. For 3.10 and beyond you can look forward to:

• Multiple WebProcesses. This is still under development, but at the very least we think we’ll be able to provide either the current “just one” model or the “one per tab” variant. Ideally also the “one per domain instance” that Chrome uses by default, but this one will be trickier. Stay tuned.
• Deeper GNOME integration. Hooking into the new Shell search APIs or the Settings privacy controls is high in our TODO list.
• Overview improvements. Animations? Access to recent history or recently closed tabs?

We think GNOME 3.8 is the best GNOME yet, and Web 3.8 is the best Web yet. We hope you’ll enjoy both, we definitely enjoyed doing our part.

0 0

Web Applications, improved

A lot of love went into making the Web Application experience better. We will now go out of our way to really find a good icon for the app, trying to use anything from Microsoft tiles, OGP icons, Apple Touch icons or normal favicons before falling back to the standard snapshot of the page content (which has been made nicer thank to the judicious use of rounded corners). We also try harder to find a proper title for the app, even hardcoding some popular ones that have really poor default page titles (hello, Facebook!). Add some small but much needed touches to the creation dialog itself, and we are good to go:

Incognito mode

I suspect there’s really not a lot to say about this that is not already well known, but anyway: need to launch a private instance of your browser in order to do sensitive tasks and minimize the risk of being tracked both on the internet and in your own computer? Well, now you can do it from the Web UI itself, just select the “New Incognito Window” option and you’ll be greeted with a dark themed window in a temporary profile that will be automatically deleted on exit. Your history and bookmarks will be copied (in read-only mode) to the new profile for your own convenience, but no passwords, cookies or other sensitive data will be carried over or stored. We are still working on some touches for this (a nice startup page, perhaps a more customized theme), but this is more than useful for now.

New search

A slick new UI for the search bar that matches the design of the other core applications and that does things like automatic case-sensitive search based on your input? Yes can do.

And more

And as usual, lots of other small details were fixed. Cleanups in our menus, fixes to the heuristics to decide where to open new tabs when Web is called from another application, support for exotic mouse buttons, the beginnings of an inline document view mode for PDF and the like, and lots of cleanups and nice refactorings to some of our internals.

Of course many other things happened throughout the hackfest, and I’ll be as anxious to read those blog posts with more updates as you are!

As always, a big thank you to all the sponsors and organizers that made the event possible, it’s always a pleasure to see old and new friends, hack the good hack, and live the WebKitGTK+ parallel life for a few days.

1 2

For a long time our adblock story was a bit underwhelming. We had an extension to do the job, but it was buggy and it would often either not block what it had to block or block just way too much (like, the entire page). So in the last cycle we pretty much rewrote the extension from scratch: it just works better, blocks what it has to block, and uses the adblock+ source filter files.

We just felt this was not enough though. Lots of people still found the wrong extension version, or were not aware there was an extension in the first place, so their experience was not as good as we hoped. So for 3.8 we are just going to bite the bullet, and integrate adblock into the browser itself. Last week we took the extension, merged it into Web, cleaned the the heck out of it, and added a simple entry point in our preferences to control it:

Of course there’s still some things that could be done, like a simple UI to edit the filter rules (for instance, to white-list a particular page where you do want to see ads), but for now we feel this is already a good improvement.

Boston Summit

In other news, I’m just a couple days away from jumping into a plane to attend this year’s Boston Summit. I’m looking forward to see old and new faces and continue the good discussions and work we started in GUADEC about the present and future of GNOME. On the selfish department, I hope to get hold of some lost designer to start fleshing out the 3.8 plans for Web, there’s so much to do.

Thanks to the GNOME Foundation for sponsoring my trip, and to Igalia for allowing me to attend the event!

1 3

The overview has landed

As Claudio already advanced the most noticeable difference in 3.6 is the first iteration of what we call “The Overview”. This is still an evolving design and implementation, but we felt that it was important to land a first version in time for this release that brought actual, solid improvements to the user experience.

What the overview currently does is easy to explain: we have changed the blank start page for a grid that holds your most visited pages. Your favorite pages are now easier to access, especially on touch devices, and we have put valuable screen real estate to work! But what about if some unwanted visitor ends up there? Fear not, if you need to you can remove them from the grid by clicking on the ‘X’ icon on the top right corner of each snapshot.

There’s more to come, but we feel this is already much better than it was, and fixes a long standing feature request for a better start page experience.

WebKit2, beta

It’s been a long time in the making, but the first bits of the WebKit2 support are already in the master branch. As we had anticipated for now it is available in beta form, which means we don’t build it by default and there’s still some functionality missing. That being said, it is really usable at this point, and doing the actual porting has helped us a lot in maturing the up and coming next generation of the WebKit framework. If you want to give it a shot, just build the browser with “–with-webkit2”, and you’ll notice:

• Increased responsiveness (how amazing the scrolling is!) and stability.
• Thanks to the OOP plugin support GTK 2.x plugins work out of the box again. That means Flash support without having to rely on nspluginwrapper.
• Other things that are there, but invisible to users, like increased security or a new and improved API, built on top of all our experience with the classic WebKit.

Fullscreen mode, now with more full and more screen

For a long time Web’s fullscreen mode was somewhat awkward. You’d still get a toolbar, so it wasn’t really fullscreen, plus it would have a strange button embedded in it telling you how to go back to the safety of the vanilla mode. Probably this was fine for the time, but with more and more HTML5 games or presentations done inside browsers, it was about time we had way of making your browser show you the full content and nothing but the content. So we just did that:

Unit testing and code coverage

This is not sexy, but I think it’s really important. For a long time our test coverage was really poor. And when I say really poor, I mean completely non-existent. Some time ago we started to add a few tests here and there, but starting in this cycle we have taken this a lot more seriously and our test coverage has grown by leaps and bounds. We have unit tests for most major classes, they are executed automatically during distcheck (so you won’t release if you broke something), and lately we have added support for the code coverage infrastructure that is now available in gnome-common (thanks Philip!). As I write these lines our coverage is around 40%, which is not great but is a massive improvement considering where we were 6 months ago. These tests have helped us to catch a bunch of bugs (some really obscure and older than some good wines), prevented lots of regressions, and helped us to do some hairy refactorings with the confidence that we wouldn’t break absolutely everything.

lib/egg, you are an embarrassment

I think these three things (having unit tests, running them automatically before release, measuring your progress with code coverage) are very important, so I’m writing another post that just focuses on how to do this for a typical GNOME project.

Other bits and pieces

As usual there are lots of additional features and bugfixes, too numerous to mention: automatic session recovery, tab-less mode, Do Not Track, using SoupTLD to make the URL completion smarter (so it can automatically figure out that google.com is a URL, but foo.bar is a string you want to search), and many more.

Onwards GNOME 3.8

But the show must go on, and Igalians never sleep. We are already working towards the next major release: in 6 months we expect to graduate the WebKit2 version of Web out of Beta status (deprecating the classic WebKit version) and land the next iteration of the overview as major new features. But those are just the known knowns, the unknown unknowns is where it’s at. Until then, happy hacking.

3 1

GNOME as an OS

As announced in our “A bright future for GNOME” talk Juanjo and myself will chair a BoF to talk about the future of GNOME. If you want to get things done and want our project to keep kicking ass for another 15 years (at least!) please come and talk with us next Monday 30th from 10AM, Room 2.1a. We intend to make this BoF productive, constructive and as little bikeshed-y as possible, your cooperation will be welcome!

Epiphany & WebKit hackfest

The might Epiphany and WebKit GNOME hackers will meet again in Room 2.1a on Tuesday 31st to hack, hack and hack. I have already committed to move the all-new Overview forward with Claudio, review the amazing new documentation submitted by Pierre-Yives Luiten, work with William on Data Sync or keep going on recently started secret projects. Some people have already approached me asking for various Ephy-related things (bug triaging, random bugs they want to see fixed), be there if you want to help!

5 1

Spurred by all this I sat down and added DNT support in Epiphany, which thankfully is an extremely simple spec to implement. It’s now in master, so anyone willing to enable just needs to go to the Privacy tab in Preferences and click:

Now the pages that choose to respect this setting (unfortunately not everyone does; by a long shot), should be able to detect your request. We can see that things are working in the donottrack.us page itself.

Note that the page claims our browser does not support the feature, yet it is enabled; this is because DNT being an HTTP header extension the only way for the page to tell you whether your browser supports it in theory is by having a hardcoded list of supported browsers, which does not include Epiphany. Oh well. Either way, enjoy your newly untraceable goodness, which should make its way into the next unstable release.

6 1

Some time ago, in another trip, I proposed anyone who might be reading me to meet up and talk about all things GNOME or WebKit. Turns out I met some interesting people that way (hi everyone from Caixa Mágica!), so let’s try again: if you are reading this, are in Tokyo, and would like me to talk to your friends/colleagues/whatever about GNOME or WebKit I’d be happy to do so. We can also improvise a hackfest or anything else we can come up with. In exchange I only ask of you to show me around (always better with a local) and an unwavering commitment to freedom and justice.

Drop me a line at xan AT gnome DOT org, or leave a comment in this space.

2 5

William Ting, Data Synchronization

William is a last year student of Computer Science at the University of Texas, Austin. He’ll be helping to alleviate a paradigmatic first world problem: I use Epiphany from so many computers that all my data is scattered around and I suffer a permanent pseudo-memory loss condition.

The battle plan is easy. We’ll reuse Firefox’s excellent design for a data sync protocol plus their free-to-use servers (we assume that’s what they were hoping for!), and will integrate the feature right into our browser. Since all the specs and implementation are open GNOME could host in the future a sync.gnome.org instance, but for now we leave that out of the scope of our summer project. Hopefully by 3.6 you’ll be able to optionally enable this functionality, cruise through the web from your tablet, bookmark that hilarious XKCD comic strip, and have it show up in your good old laptop just like that.

I’ll be mentoring this project myself, which was initially proposed by Igalia’s very own Joanmarie Diggs.

Yann Soubeyrand, Anti-phishing Support

Yann is a first year student at the École Nationale Supérieure d’Informatique et Mathématiques Appliquées de Grenoble. His task will be to solve a complicated problem that Epiphany has suffered for a long time: for most users the information provided in the URL entry is not enough to judge whether the page they are visiting is safe. The SSL or certification data is useless for most people, and by showing scary warnings about things they don’t understand at best you’ll train them to just click through to get to the content. To make things worse, most of the time those warnings do not actually indicate someone is trying to scam you, just that apparently setting up web servers correctly is difficult. So all in all, while useful, the information we currently show in the UI is really not that great for the 99% out there.

With this in mind, we’ll try to do the following: using the Google Safebrowsing APIs we’ll try to request authoritative information about the potential “phishiness” of the pages you visit. If we get a warning through this channel we can be confident about there being a security threat, so we’ll show a big, clear message on top of the web content. No jargon about outdated certs or VeriSign trying to take over the planet, just “Listen, our best people tell us this page is almost certainly not safe. Let’s not go there.”. We think this will significantly increase the safety of the browser without violating the user’s privacy, since Google’s API do not require you to disclose the pages you are visiting to validate them (magic? no, science).

Sergio Villar will be mentoring this project.

That’s it, let’s roll

That’s it for now. We’ll make sure to keep you updated about these and other developments in GNOME’s very own web browser. Thanks to GNOME for choosing our proposals, to Google for sponsoring Summer of Code again, and of course to Igalia for its continued support for GNOME and for allowing us to spend our time mentoring the fearless next wave. Happy hacking!

2 3

New UI

The most obvious change at first glance is the refreshed UI, which was already covered in some detail in this blog post. Thanks to the hard work of the GNOME Design Team, the GNOME platform hackers and the Epiphany team we’ve got ourselves a completely new toolbar layout with elegant widgets (I particularly like the linked-style back/forward buttons), support for the new Shell application menu, the demise of our menubar and the debut of our ‘super-menu’ holding the less frequently used page specific actions. Not only the browser works better than ever, it now looks better than ever too.

New History

We have been talking about rewriting our history backend for many years now; to give just one example, as far back as 2007 we already had a Summer of Code project to try to fix some of its shortcomings, which were many. The old backend served us well for almost a decade, but it was showing its age: a difficult to understand legacy codebase, a bus factor of 1 and poorly scalable architecture that made storing more than a couple of weeks of browsing history a titanic task. Last year a crack team at Igalia was put together to fix this once and for all. Enter the new age:

• Drop our XML based storage in favor of good ol’ SQLite. Many options were considered other than SQLite, and we could yet again change how things are done internally in the short term, but for the first step we decided to settle on a simple, trusted and performing technology.
• Never block the UI. All actual history accesses are done in a special service thread which communicates its results when they are ready to the user interface. This way things will remain responsive and snappy, no matter how complex your queries are or how full to the brim your history is of non-stop reddit browsing.
• Test it! User data is the most important thing the application handles, and losing your browsing history is the modern day lobotomy. Our new backend is thoroughly tested through unit tests, so your data is in good hands with us.

Thanks to the new backend we can now provide infinite history storage and instantaneous non-blocking search both in the URL entry and the history window, both long awaited features. Other than that, for 3.4 we tried to keep the UI as it was: one thing at a time. For 3.6, though, now that the we are beautiful on the inside, expect some surprises in how you interact with your history data.

New WebKit

As with every release, on time, we ship with the all new WebKitGTK+ 1.8. As usual there are way too many thing to list and they deserves their own blog post, but you can look forward to: the debut of the WebKit2 API (still experimental but with some modules already using it, like devhelp), WebGL, Accelerated Compositing, HTML5 History API, support for the last version of WebSockets, WebAudio, a rewritten favicon database class and loads and loads of bugfixes and improvements.

Less is more

A constant thought in my mind as a module maintainer is to focus our efforts in delivering the best experience we can given our available resources. I believe as a project, both GNOME and Epiphany, we are now facing the difficult choices successful software must go through at some point: stop trying to be everything for everybody, decide what you want to do and for whom, and try to do that really well.

Our new ongoing redesign is a great step in that direction, and I’m glad that we are finally focusing on what I think really matters. I believe 3.4 is our best release ever, with both cool new features and fixes for old major deficiencies, and things will only get better from here. And, a favorite pet peeve of mine, we did all that while massively cleaning up our codebase to make it cleaner and more hackable, a task without much glamour but a big payoff. Our last release, ignoring translations, icons and help files, comes with 214 modified files, 14,959 insertions and 24,341 deletions. For those keeping the score at home, that’s almost 10,000 lines less of code to maintain, read, patch and load!

Thanks!

Thanks to all the GNOME contributors that made possible this release, but a special thanks must go to Igalia for its continued support for Epiphany. We are not only the best WebKit consultancy around, but we are also putting our money where our mouth is by supporting web technologies in GNOME through its browser and beyond.

Work on 3.6 is already underway, so expect a lot more from your favorite webkittens 6 months from now. Until then, you can follow us on IRC, our mailing list, identi.ca, twitter, facebook or our new project page (wow!). Happy hacking!

3 2

There’s a lot of new stuff here, so let’s go step by step.

Application menu

The application menu, accessible from its usual location in the Shell, holds actions that affect the entire application as opposed to the currently focused window or tab. You’ll need a fairly recent version of the Shell and gnome-settings-daemon (3.3.4 of both should do, when they are out) to get it working, otherwise the browser will fallback to a lonely “Application” entry in a now deserted menubar.

Also, notice that we now brand ourselves as “Web” in all user visible strings.

New toolbar

The bulk of the changes are here. As you can see the Back and Forward buttons have been visually merged, a fate shared by the location entry and the reload/stop button. The entire menubar is gone, being replaced by a “super menu” triggered by the funny looking button with a gear (more on this later). Everything else that used to be in the default toolbar layout is now gone, as is the ability to edit its contents, making the concept of a default layout more dramatic. Finally, we use a new style for the toolbar, making it seamlessly merge with the window decoration. We think it looks great!

Super menu

In the quest to save as much vertical space as possible in the default layout we have moved all the remaining actions of our menubar into a side “super menu”. Here will live actions related to the current page, although for the moment we have some visitors there en route to their new destination (like the Bookmarks menu, which will live in the new Overview).

The devil is in the details

A lot of other small tweaks and cleanups have happened, too many to mention. From a renewed floating statusbar (now shared with Nautilus), to spacing tweaks, to more thorough use of symbolic icons throughout the UI. Special thanks go to the Design Team, it’s a pleasure to work with them in both the small details and in the big picture re-designs.

Also, one benefit of having a renewed design focus is that it allows you to do this:

135 files changed, 14988 insertions(+), 26958 deletions(-)

Around 12,000 lines of code have been deleted since 3.3.2; the biggest chunk comes from the demise of EphyToolbarEditor and friends, but in other places we have just managed to do the same, or more, with less. This means more energy devoted to make Epiphany really good at what it should be doing, which is what every core GNOME application should aspire to do.

More to come

This is only the beginning, not the end. The Epiphany team will now continue full steam ahead to implement the new Overview, merge the new SQLite history backend, port our extension system to libpeas and many other exciting features, maybe including some surprise gift in the Web Application camp. Stay tuned to this space and, as usual, happy hacking!

5 0

The design is still very much a work in progress, but I can try to briefly talk about some of the highlights of the refreshed concept:

• Focus on the current page content. This means, in general, that we’ll get rid of as much chrome as we can (a trend that we started some time ago already), and in particular and more visibly that we won’t have a visible tab bar by default.
• The tab bar might be gone, but we’ll still offer a convenient, and we think improved, way of switching between pages. All the currently and recently opened pages are visible in the overview (the new start page), and we’ll provide a way of switching between them with the mouse or keyboard shortcuts. You can see an early animated mockup of this in this video of the gnome design youtube channel (link to the video):

• We have tried to identify and make easier other tasks that have been historically solved with tabs. One of the most common ones is “I want to read this web later, I’ll save it in a tab”. Epiphany will now provide a specialized mechanism for this, called Queues. The design team is working on the details of its implementation, but we have already some interesting ideas; for instance, when you open links in a Google Search results page with middle click a new queue could be automatically created with the results page as the parent and all the links you open as items in the queue.
• There’s many more ideas that are either refinements of already existing features, like Web Application integration, or nailing down the last details of long-term developments, like improved stability and performance thanks to the upcoming WebKit2 support. Make sure to follow the GNOME Design team or Epiphany channels to keep in touch with things as they evolve.

The mighty Igalians (namely Claudio and myself) are already busy at work implementing the new design. For now we are focusing on a series of incremental patches that will move us closer to the end goal, that way we’ll have something usable even if the design or the full implementation of the Web application are not ready in time for 3.4. You can check the current Roadmap, and as always if you want to help us just drop by #epiphany @ GimpNet or send an email to the epiphany-devel mailing list.

Until the next time, thanks to all the attendants to this year’s WebKitGTK+ hackfest, and to all the sponsors for their support. Happy hacking!

2 2

It is a bit besides the point of this post whether a platform is
popular because it has half a million applications or whether it has
half a million applications because it’s popular; the truth is likely
that popularity and a lot of applications go hand in hand in a
self-reinforcing loop. That being said, the fact remains that any
platform that aims to be relevant needs to both convince developers to
create applications for it and to provide them with the means to do
so. If you start with an eye-popping, years ahead of its competition,
money-making miracle thing like the iPhone you might end up convincing
large amounts of people to target your platform specifically, but
usually having a great platform won’t be enough to do so. Think of
WebOS.

The question for us is, then: how are we going to get from where we
stand today to a vibrant constellation of applications centered around
the GNOME platform? Is there a path from today to 500,000 GNOME
applications in the future?

Developing GNOME and for GNOME.

The way things have worked so far is that we expect people to develop
for GNOME in a similar way to what in which we develop its core
applications. This is not only natural, but also has some great
qualities like making us dogfood our own development processes. It has
also some disadvantages, like expecting (perhaps unreasonably) all
developers to appreciate the perhaps too hacker-like tools we use and
routines we follow. Maybe not everyone wants to use the shell, emacs
and git from the command line? Perhaps we can jump without problems
from C or JavaScript to Vala (the 3 languages currently used in the
core module set), although I have my doubts, but surely offering 5
different language alternatives in developer.gnome.org, with tutorials and API documentation, without really telling newcomers which one is recommended, encouraged or best supported might be too much for most people?

To the extent that our core development practices are reflected in our
third party developer story we need to keep our house in order. Being
able to use any language to target GNOME might be a strength, but the
fact that we cannot decide which language we want users to learn first
might perhaps just be the result of our internal confusion. The core
libraries are still overwhelmingly written in C, but all the new
generation applications and UI modules are being written in higher
level languages (finally?!). Which ones? Well, guess it
depends. Some use JavaScript, some use Vala, others might come in the
future, and it seems that the winner mostly depends on the tastes of
the module owners. Surely not all languages would be tacitly accepted
(sawfish was dropped, among other reasons, because it was written in a
dialect of Lisp), but I can see the situation getting worse before it
gets better.

Even if we sort out the language issue there would be further barriers
for new developers. Our platform has been massively cleaned up in
recent times, but the road to GNOME 3 has created new ambiguities: a
parallel, mostly internal, toolkit built on top of Clutter is used by
the Shell or Sushi, and if certain animations or effects are desired
in GTK+ projects the only choice seems to mix and match a bit of the
old and the new in the same application. Efforts are underway to unify
things, but again it’s not complicated to see how someone new to
the whole thing might be confused.

I could go on mentioning communication channels, tools, etc, but I
think the point has been made: as far as we expect people to develop
native GNOME applications in a way similar to how we work we need to
spend energy in clarifying our internal procedures, documenting them
and publishing easy to follow and simplified instructions for third
party developers. Otherwise GNOME will likely be perceived as a
platform that is difficult to develop for, best suited for expert
hackers, with few quality applications and not much appeal for the
mainstream. This would have been a reasonable conclusion some years
ago, and has been a repeated call to arms in the past. While I think
it still makes sense to do this, I believe we live in a time that
offers us new strategies that we can combine with this one, perhaps
better suited to our current capabilities and resources.

The Web.

The Web is winning. This horse has been beaten to death, so I won’t
dwell on the details at this point, but web technologies are here to
stay and are only becoming more and more important each day. Those who
repeatedly announce the imminent failure of the web as an application
development platform on the basis that it, well, sucks (and it kinda
does) miss two important points: first, the web is winning not because
it’s a beautiful platform, but because of its reach. Second,
whatever its flaws, the web platform has so much momentum and energy
put into it that it’s quickly overcoming most of the defects that it
had at some point, and things will only improve. Do you want an idea
of how big this is getting? Windows 8 applications will be built
using HTML and JavaScript. You don’t get more mainstream than that.

A new array of solutions designed to build web applications (packaged,
delivered to the user, run locally) is being created as we speak. From
Tizen’s endorsed WAC, to Mozilla’s OpenWebApps, to Chrome’s
Applications the list keeps growing in expansionary fashion, but
all the specs share the same father: a thin layer on top of HTML5, CSS
and JavaScript, bridging the gap between the W3C standard’s and the
needs of the apps. As the standards grow, those platforms will shrink,
and it is likely that in good time a reasonably standardized solution
will emerge.

Why is this relevant for GNOME? Never mind iOS, never mind Android,
one thing is clear: most of the next million apps written will be web
applications. Some huge players like Microsoft are already moving
there as fast as they can, and the rest will follow sooner or
later. Native apps won’t go anywhere for a long time, but developers
willing to maximize their reach will, increasingly, prefer web
applications over anything else. At least as their first choice. This
brings us a great opportunity. If we jump on this bandwagon, support
web applications as first class citizens on top of world-class
runtimes, and accept and even encourage people to run their web
apps on our operating system we can maximize our reach with a
fraction of the effort of fighting in the native SDK war against Apple
and Google. I think being smart in how we spend our scarce resources
is important, and I believe this is a fight that we can win if we put
our minds to it: let’s not forget our own platform, but let’s embrace
the web as it is emerging.

Most of this was shared with those present at this year’s GNOME Boston
Summit (in Montreal), and although there was a lively debate my
impression is that most of it was well received by the core hackers
present. We at Igalia believe that this is a promising way forward for
GNOME and we happen to have the skills necessary to make it happen, so
we are committed to keep investing in the foundational platform bits
like WebKit and to bring Web Application support to our OS: our plan
for the next months is to explore all the new technologies I have
mentioned, and start to implement a well integrated runtime to run the
next generation of web goodness at home.

1 4

To this:

in less than 4 hours. We are just that cool. Welcome Joanie!

2 1

The main idea here, to give a bit of context, is that some of us use a certain number of web pages as if they were applications: we open them the minute we open the browser, keep them open all the time, check on them periodically, etc. Once you figure this out, the next logical step (sort of “independently discovered” by pretty much anyone doing browsers) is: well, if you use them as applications shouldn’t you try to make them a bit more like actual applications? Right. So let’s see how we have done this in GNOME.

Let’s say you are using a certain micro-blogging service with a blue logo and a tendency to break down from time to time. At some point you figure you use this thing so much that you might as well create an app for it. Press Ctrl-Shift-A, or access the File menu and select “Save as Web Application…”:

Now a small dialog pops up. It will present you the icon to be used for the new application and a tentative title, which you can edit. If the page is providing a specific high-resolution icon (usually meant for touch devices like the iPhone) we’ll use that, otherwise we fall back to a screenshot that will hopefully be recognizable enough. There’s lots of smalll improvements to do here, from overlaying the normal favicon on top of the screenshot to allowing the user to select the region to snapshot (or even scrapping the page trying to see if we can find the logo somewhere), but those can come later.

We click “Create”, and the system informs us that the application is ready to be used.

If you click “Launch”, or access the newly created application from the Shell, you’ll get a new browser instance in the so called “application mode”.

Very briefly:

• There’s absolutely no UI chrome other than the title bar.
• The application is sandboxed to a given domain. If you try to go somewhere else, say by clicking a link, the petition will be forwarded to a normal browser instance.
• The existing cookies for the application domain are inherited from the main browser profile (so that you don’t have to login again), but other than that this is a completely fresh profile.
• Finally, this is running in a different process. If you crash your main browser your Twitter app will still be there.

And that’s pretty much it! I have been using this intensively for a while now, and I must say it feels totally natural and, for me at least, it provides a much more convenient way of using the web applications that I’ve come to rely on. I’m eager to get feedback from the early adopters using 3.1.90, and with a bit of luck even patches fixing the low hanging fruit!

Until the next time, happy hacking!

Edit: a bunch of people are asking whether the apps show up in the overview, in the dash, whether they can be pinned, etc. The answer to all of that is: yes. The web apps created through Epiphany behave just like normal apps. You can launch them from the shell, they show up in the dash and you can pin them there as favorites if you want.

3 0

Alice: Oh, there’s problems in our relationship, but it’s nothing. Just small things that annoy me.

Bob: Then there’s nothing to be done. Small things are all that matters in the end.

It is, of course, an exaggeration, but one of those that can perhaps hide a deep truth. Maybe because in many cases small things are indicative of bigger problems, or maybe because we very easily take for granted the parts that work and end up obsessing with small details to the point where they ruin the whole experience for us (see: Death by a thousand cuts).

In any case, in the last weeks we Igalians have implemented a few nice improvements in Epiphany, all of which are available in GNOME 3.1.2. Only small things, but they matter.

Spell checking

Spell checking! I know I hate writing long chunks of texts without it, and I’m probably not the only one. We enable the feature by default, and will perform spell check using the languages selected in Preferences→Languages or, if there’s none, the default system language according to GTK+.

But of course knowing that you have made a mistake is only half of the battle. If you right click on the misspelled word you’ll get 4 suggestions from WebKit to use as corrections. Click on any of them and it will replace your blunder.

Warning on leaving pages with unsubmitted forms

A feature that old-time Epiphany users will remember fondly. Has it ever happened to you writing a huge comment on reddit, or perhaps a fantastic resignation letter to your boss, only to accidentally close the tab losing all of it for good? Yeah, me too. We will now detect this unfortunate situation, and warn you one last time before tragedy ensues.

Hide that menubar

An ability I enjoy from our terminal is the possibility of hiding its menubar. It’s nice to regain those pixels if you are rarely using them. Since imitation is the most sincere form of flattery we went ahead and copied the feature almost verbatim. Right click on any chrome area in the browser and you’ll see the option to show or hide the menubar:

When unselected the menubar will just go away, although you can always bring it back by performing the same action again. The result? Well, there’s not a lot more to hide now!

Symbolic icons in the URL entry

Jon McCann (repeatedly) asked for Epiphany to drop its yellow tint in the URL entry for secure sites, and Cosimo Cecchi suggested in a bug that we should also use the new symbolic icons for the security lock. Both great ideas, which combined give us a more modern look.

about:plugins

about: support finally landed, and with it about:plugins. There’s a few more things we should add here, like the full path of the plugin and a checkbox to disable it, but at least now it should be easier for users to figure out whether the browser knows about a particular plugin or not.

Also rumor has it another well-loved about: page made it into the release, but you’ll have to figure out that one for yourselves.

5 0

Epiphany 3.0

Yes, the Bluetooth/Network icons are all wrong. Sorry Jon.

It’s always hard to summarize months or development in a few lines, but one can always try:

• Epiphany 3.0 uses the (soon to be released) WebKitGTK+ 1.4.0. I’ll write a blog post focusing on WebKit when 1.4.0 is out of the door, but some of the highligts of the release would be: GObject DOM bindings, already used by Epiphany and other GNOME apps. HTTP cache implementation, moved into libsoup later in the cycle. GTK+ 3.x support, which we laboriously kept going through all the development cycle. New APIs for plugin management, icon database and frame flattening, among others. HTML5 media support for fullscreen mode, volume management, cookies and Referer. A ton of bugfixes all across the board, from DnD, a11y, networking, and graphics performance to leak fixes, clipboard handling, history, theming and forms. WebKit 1.4.0 just works a lot better, and you’ll notice the minute you start using Epiphany 3.0.
• UI refinements all over the place: we use a GtkInfobar to inform of session restoration, a Chrome-like floating statusbar (implemented with GeditOverlay) instead of the pixel-eating traditional GtkStatusbar, we let the old, big and hardcoded EphySpinner go, new and nicer custom error pages, …
• The download UI was completely rewritten to fit better in the Shell. No more status icons and floating windows, we now show ongoing download information in a unobtrusive bottom bar.
• We took the GSettings migration as an opportunity to improve a bit our settings. In particular I think we have made the font defaults saner for the modern world, and hopefully people will be happier with how their pages look.

There’s still some small details that we want to improve for 3.0, so stay tuned for 3.0.1 (and more!) soon.

Epiphany 3.2

But we are not resting on our laurels! We are already busy planning and working on the features you’ll see in GNOME 3.2, 6 months from now:

• One of the main themes of the release will be further integration of the browser with the new GNOME UI and design. We are still in the brainstorming phase, but some of the front runners are replacing our menubar with the Shell’s global app menu (more space for your web content!) or integrating our tab/window management into the Shell user experience.
• A desktop that does not consider the Web a first class citizen in 2011 is not a modern desktop. For 3.2 we are going to bring your favorite web applications into the spotlight: hi-res launchers with custom .desktop files, separate epiphany instance per application, minimal chrome-less UI, and much more. Also, we have proposed this as one of the GSoC ideas for GNOME in 2011.
• We are also resurrecting the old idea of killing EphyNode and moving our bookmarks and history storage to something like sqlite, which should give us a much more faster and responsive experience. Martin and I are committed to get this working before I leave the Bay Area in May, so if by that date you see me around and this is not in master or in a git branch you can punch me in the face. Really.

One more thing

A year ago, almost to the day, the WebKit2 initiative was announced. As the project page says,WebKit2 aims to bring the split process model popularized by Google Chrome into the WebKit framework in a way that will allow all ports to benefit from the increased responsiveness, security and stability. At Igalia we have always been interested in bringing this new technology to our GTK+ port, and only a few days ago the last batch of patches in a long series finally landed upstream, allowing everyone to build the GTK+ version of WebKit2 directly from SVN trunk (you can read more details in Alex’s blog post!). We believe a split process model has quickly become a must-have for modern browsers, so we want to announce our commitment to port Epiphany to WebKit2 as soon as it is ready, and make this the default and only configuration available, as in Chrome. We are aiming to have an early alpha to show at GUADEC this year, and we’ll try to deliver a production ready version as early as GNOME 3.4, in 2012. We hope you’ll all be as excited as we are about this new stage in the history of the GNOME browser!

Until next time, happy hacking from your favorite band of gnome web hackers.

8 0

On February the 11th the descendant of what once was my first project as a professional developer finally crashed and burned in a re-enactment of the now legendary GTK+ to Qt gambit, also known as “let’s dump everything and start from scratch because we are not sufficiently behind of our competitors”. Those of us who thought that the switch to Qt was for the most part a vain quest for a technological Grail that would save Nokia from its own structural and management related issues were probably not terribly shocked, but it’s hard not to be sad about the way things finally happened. In any case, I’m not here to write about whether Stephen Elop is a fifth columnist, about Windows Phone 7, about the future of Qt, about who-gives-a-crap-about-toolkits-anyway-the-Web-won-guys or anything of the sort. I just want to talk about one thing: for many years Free Software was Nokia’s hope for a better future, a wagon they shared with many of us. After years of rhetoric about the virtues of openness and the wonderful vistas of synergy now available to the boldest of the middle managers, if only they were a little adventurous, we are supposed to accept the harsh cold truth: the best way to do software is to do it behind closed doors, the future belongs to proprietary platforms, nothing good ever came out of geographically distributed cooperation. Well, I disagree with the keen minds of the North. Perhaps what I have to offer is a controversial proposition, perhaps in the XXI century it’s a bit passé to show deep commitment to some ideal other than the quarterly reports, arrogant to pretend that you know better than others, but what the heck: Nokia is wrong, and we are right.

We live in a cynical and difficult world, where those who have a lot tend to only want more, and where the rest of us must juggle with morality, trying to get along as well as we can without reaching a point where we cannot look at ourselves in the mirror anymore. Some ideas are perpetuated in order to keep us happy enough with our lives, not questioning too much the quotidian farces we face, and one of those is this one: closed software is as good and respectable as free software, you should use whatever is best for you, your company, your shareholders. Well, it’s not. Never has, never will.

Some truths are simple enough to be taught to kindergarten children, simple enough to be only questioned by adults: sharing is better than hoarding. Contributing to the general well being of humanity is better than keeping the improvements you do for yourself, for profit. This was true when a certain Mr. Stallman decided he’d write a Free Operating System in 1983, and it’s still true today. It will still be true when anyone who is reading this today is dead, when all the closed software that ever was is also dead and buried (and believe me, it will), when the only software remembered, and used, is free, improved and built upon by our descendants. It might be hard to believe, in the era of the iPhones, that this will ever happen, but if you are reading this perhaps you share my controversial ideas. Perhaps you also think Nokia is wrong, and we are not. If you do, and you are hacking the good hack, keep going, I’ll be right behind of you.

11 0

If this sounds like something you’d like to do drop me a line to any of my multiple mail addresses (I’m sure you’ll manage to find at least one of them) with any background information that you consider relevant.

PS: We are extremely flexible in both location (ask me about my last 9 months travelling around the world) and how you distribute your working hours, so we should be able to accommodate pretty much anyone that is both human and living on planet Earth.

7 0

Others have already blogged about the event (Mario, Gustavo, Alex, Diego in multiple occasions … eh…) in some detail, so I’ll just try to give some extra information about some of the things that I did.

JIT + Oprofile

One of the few negative side effects of the not-so-recently acquired JIT superpowers of JavaScriptCore is that JIT-generated code does not play very well with the tools we use everyday to debug and improve our code: gdb will have no idea of the name of the chunks of generated code it passes through (since they have none), and will print something unhelpful like “#9 ??”, profile tools like oprofile and sysprof will have exactly the same problem, so you’ll be unable to know which, if any, of the generated code is the culprit of excessive CPU usage, valgrind does not expect executable code to modify itself at runtime, and will freak out and crash unless instructed to not do so, etc. Fortunately some of these problems have solutions, so I spent the beginning of the hackfest reworking (to please the Reviewer gods) a beautiful patch started some time ago by Holger Freyther and the wizards of the University of Szeged to instruct oprofile about our JIT maneuvers. With this in place the tools is able to know the context of the JIT memory chunks it goes through, and is able to go from some useless complains about anonymous memory ranges to printing something like:

141       0.1910  8581.jo   <jit-func>:fannkuch[tests/sunspider-0.9/access-fannkuch.js:5-62]

Nice!

about:plugins

Another topic where I spent a few days is the long struggle to resurrect “about:plugins” in Epiphany. While Dan was busy kicking libsoup into shape so that we can implement about: URLs in a non-terrible way, I worked on adding the APIs in WebKitGTK+ that the browser will eventually use to fetch the plugin data. A couple of patches (here and here) have already landed, and we can now query WebKit for all the plugins it has loaded in the session, ask information about them, and even disable and enable them at runtime. Because seeing is believing you can see a hacky implementation of the about page that I have implemented locally:

Rest assured, this will look nicer (and will have more data and features) when it finally lands upstream!

Tradition

It was of course great to see everyone again, both colleagues from Igalia and all the other hackers, and I hope we’ll be able to repeat the event again next year. If we manage to do it a third time this would pretty much become an ancient tradition of the GNOME community as far as these things go. Thanks to all the contributors and sponsors (Igalia, Collabora and the GNOME foundation) and until next time.

4 0

It has come to my attention that the GNOME Foundation is interested in my DEFCON app in order to better enforce the new Speaker Guidelines in current and future GUADECs. I’m happy to announce that the app is in fact for sale, so just contact xlopez at igalia.com for details.

PS: starting price is 500 EUR, it includes a tactical nuclear strike to the talk site when DEFCON 1 is hit.

3 5