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!

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.

To this:

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

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.

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.

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.

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.

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.

2.30

For 2.30 we focused on fixing all the regressions introduced by the switch to WebKit in 2.28. Overall we did a pretty good job, and there’s only a few things missing to reach the no-regressions goal. Here’s everything that used to work in 2.26, didn’t work in 2.28 and that we fixed for 2.30: middle-click to open clipboard contents, bring back our old context menus, up arrow functionality, do a web search with the URL entry contents on Ctrl+Enter too, EphyEmbedSingle::handle-content signal for external download managers, favicon support, send HTTP ‘Accept-Language’ headers with the user language preferences, custom User-Agent support, javascript: and mailto: URI support, close and movement DOM methods for window, shift+click in text areas, and, yes, form authentication auto-completion.

Wew.

OK, so that’s a lot of stuff, but we were not happy with only bringing back old functionality, we also made some improvement here and there:

GNOME Keyring storage for form auths + Infobar goodness:

In 2.30 not only all your form authentication data is stored in the keyring, but we walked the extra mile to migrate the data in the gecko profile to the new format (not a particularly funny thing to do) and we now show a shiny infobar each time you are about to submit never-seen-before data:

Page cache

After much painful debugging we managed to make the Page Cache support in WebKitGTK+ stable enough for widespread usage. These means that when a page passes some preconditions its whole in-memory representation will be saved for some time, making going back to it with the Back/Forward button blindingly fast. Fast is Good.

Favicons in the Tab Menu:

Back in 2007 I opened a bug suggesting to put favicons next to the page titles in our Tabs menu, arguing that this would make it much much easier to identify a certain page when you have lots of tabs opened; having said that, I promised to attach a patch with the fix “soonish”.

3 years and one week later Olivier Tilloy probably got fed up of waiting and decided to just send a patch himself, making our lives (well, at least mine) much better:

Hey, can you see the bug in that screenshot? An opportunity to contribute!

Disable all plugins at runtime:

Back in the day all you could do in Epiphany was to disable the Java plugin, which nowadays is, to say the least, a feature of questionable usefulness. What we all want to do, surely, is to disable Flash unless we actually need to use it, right? Actually, make it all plugins in general, just in case:

Now

And what about the next release? We haven’t stopped working. In fact at Igalia we are increasing our commitment with the platform, and we are growing the team: Alejandro García is working on rendering performance and in reminding everyone how many years it takes to get anything done in software, always; Sergio Villar is working on libsoup, aiming to finish the disk-cache for 3.0; Mario Sánchez is focused on our accessibility support, fixing bugs left and right (with the help of two of our interns, Diego Escalante and José Millán); Philippe keeps rocking on the media front, and our most recent hiring, Martin Robinson is rewriting and improving our DnD support so fast that it’s hard to keep track of it! Oh, and yeah, myself I’m still working on the GObject DOM bindings, a new post about all the new features I’ve added these past weeks is way overdue.

And what about Epiphany? For the next release (due on Wednesday) you can expect a bunch of bugfixes and some UI improvements. One that I’m enjoying a lot is something I implemented last week; I finally got rid of our statusbar for good, and now by default we’ll show contextual messages in a Chrome-like embedded statusbar (which we already had, but that I have reimplemented and made visible by default):

More vertical space for web content, less code!

My goodness was that cheese good

After finishing some loose ends in a remarkable place I found in Bairro Alto the GObject DOM bindings are in good enough shape to start doing some damage in this world (queue video that probably won’t appear in Planet GNOME, click into my blog to see it):

What you just (hopefully) saw is a GTK+ button that, when clicked, gets all the links from its cousin WebKitWebView and makes them do a small bounce, all with the DOM APIs you know and hate^Wlove exported through GObject.

For instance, to get all links simply call webkit_dom_document_get_links on the WebKitDOMDocument associated with the WebView, which will return a WebKitDOMHTMLCollection. Now we just iterate through the elements, get the WebKitDOMCSSStyleDeclaration associated to each one, and set the CSS properties we want on each one. Simple as that! No “evaluate this string as JavaScript”, and no using the JavaScript bindings through JavaScriptCore. In fact, since we are generating our own bindings instead of using the JavaScript ones, we can get the proper semantics for GObject toolkits instead of having to live with the decisions other people made for other languages and contexts. You can see the code snippet here; I use a two-step animation instead of using the full-blown css transitions because of a small technical issue that I didn’t want to fix before pushing this post, but of course we should be doing it right in the future. In fact, we should create proper APIs for CSS animations in general, not too different from what you have in, say, Clutter.

Most of the code for this is already in Webkit trunk, and now that the initial phase of the work is done I keep improving the code incrementally and pushing the patches to bugzilla, where my compadre Gustavo promptly reviews them. Now if you’ll excuse me I’ll go to expose all events as glib signals on the DOM objects, watch this space (or the upstream bug) for more updates. Happy hacking!