Epiphany meets the web app stores

In last weeks, I’ve been taking a look at the web applications standards support in Epiphany, as part of my work at Igalia. Xan wrote about the Save as web application feature present in Epiphany 3.2, that is a base for very simple (and userful) web applications support in Gnome desktop.

To continue with this work, I’ve been investigating on adding support for some web app stores. So I’ve done an experimental implementation for Mozilla Open Web Apps (as in 2011 tech preview), Chrome Web Store hosted and packaged apps, and Chrome CRX-less apps.


Screencast using Chrome Web Store.

This is an experiment. Not supported, and it may actually stay out of official Epiphany. So there are lots of things not working at all. This is first a way to have a big number of apps to play with our application mode, and improve it. So no permissions check, URL’s match may be broken, many apps will fail to even log in… Did I say it is an experiment? Most obvious issues are related with this external links handling bug.

But, if you just want to play with it, just try my branch webapp in my Epiphany Github repository. By default, support is disabled, so you’ll have to enable these keys:

$ gsettings set org.gnome.Epiphany.web enable-chrome-apps true
$ gsettings set org.gnome.Epiphany.web enable-open-web-apps true

You can try with Mozilla Labs Apps Dir from 2011 tech preview and Chrome Web Store.

8 comments

  1. nice one, keep up the awesome work

  2. We always want to emphasize that these apps are regular web apps — really anything that runs in Chrome or other modern browsers today could be turned into an installable web app < http://code.google.com/chrome/apps > with a minimal amount of extra glue (including apps that use Silverlight, Flash, Native Client, Unity, etc).

  3. I was doing a search on Chrome and Epiphany and came across this blog. While incorporating apps sounds pretty cool, an extension compatibility would be more awesome. There are pretty good extensions for Chrome that could be useful (like bit.ly, iReader, etc.). If we could just use them in Epiphany… :)

    • José Dapena Paz

      Sure, but implementing extensions is a far bigger effort. We could try to support a limited subset, but in any case, Chrome extensions are not a public standard nor it intends to be that. So, as API grows and changes, we would be playing the cat&mouse game.

      My idea is focusing more on open standards, and only add chrome extensions-like stuff in case the effort to keep up with standard is not big.

      • I’m not an expert on Chrome extensions, so I’m just guessing, but aren’t they more easily implementable than let’s say Firefox extensions? Chrome seems to be more like GTK based, with a few Clutter stuff here and there afaik, while Firefox is XUL. I don’t know if that makes it more compatible with an easier workaround. I’d love to use Epiphany because it’s visibly growing into a mature browser, but those few extensoins force me to use Chrome. I’m fine with it though, but it could use better Shell integration (as it already has Unity integration features).
        So, anyway, some sort of compatibility layer would be great, but not urgent or something. :)
        But thanks for the rest, I’ll give it a run with Fedora 18 if it gets implemented by then. ;)

        • José Dapena Paz

          In fact, one of the great things of Chrome extensions API is that it’s basically some javascript API’s available for applications. If you want to support applications using them, you just have to implement those API’s.

          But, they’re already a lot of them. So there’s the point of choosing very well which ones to support.

          And also, some of them are very specific of the user experience in Chrome (toolbar behavior is different, tabs are different, web applications, etc). An example: in Epiphany web apps run in a different window, and show as different applications. In Chrome most applications are designed to be run in same Chrome shell, in a tab.

          So, that’s not really decided what to do with all of these. My idea currently is moving the Chrome store and extensions support to be an Epiphany plugin, and try to state as clear as possible that this support will be experimental (we don’t want to promise we’ll keep up with any extension or change in API’s in Chrome as we don’t have resources for such an effort).

          • Despite some very good points, I really think the focus of your efforts here should be on implementing the Extenions API. There are a wide variety of chrome extensions already available and many developers target chrome because it is so widely used. Moreover, suitable implementations for most of the functionality should be in the Chromium repository. This seems a lot easier and more useful than developing your own Extensions API as seems to be the direction Epiphany is headed in.

  4. […] Do you think this is exciting? Well, there are some more optimistic ideas like an Epiphany Data Sync. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>