So, we made it in time for the release. After months of hard work 2.28 is out, and hopefully it will hit a repository near you (in case you are not so much into hunting projects in their natural habitat). Some reviews think Ephy/WebKit is not too bad and appreciate the effort we are putting into bringing WebKit into the platform, so I guess we can be happy of our progress so far.
Speaking of WebKit, we branched for our semi-stable 1.1.15 release. After some talks we decided to not declare our APIs stable yet, since the development is still advancing very fast and we could use a full cycle of testing to see what works and what doesn’t, but nevertheless we will support 1.1.15.x as a stable release in every other aspect: no new features, only bugfixes and patches for security issues, supported until the next stable release is out. It’s the recommended companion for GNOME 2.28, so distro guys you know what to do! And, just to see if anyone was paying attention, we quickly rolled a 1.1.15.1 with a couple of important bugfixes; you can get it at the usual place.
2.30 – The Future
But enough talk about the past, what will the future bring?ย These are some of the things that we plan to do, or at least get started, for 2.30.
GObject DOM bindings
WebKitGTK+ already provides APIs to do most of the things applications need to do when dealing with Web widgets, with one very big exception: access to the DOM. DOM manipulation has to be done, as of today, through sad APIs like webkit_web_view_execute_script, which make doing anything other than trivial things pretty cumbersome and difficult to debug. Wouldn’t it be nice to be able to access the page contents through nice GObject APIs, with bindings for all languages through gobject-introspection? Yes, it would, and it clearly is what we are missing to be able to create a new kind of GNOME applications. Other ports, like Mac or Qt, already provide something like this, so clearly we have to step up to this challenge ๐ Expect to see, at least, basic GObject DOM bindings for WebKitGTK+ in time for GNOME 2.30.
GNOME shell integration
An idea that has been floating in my head since GCDS is to try to integrate Epiphany more closely in the coming brave new world of GNOME Shell. I think our UI can be kept simple and usable and at the same time updated to use all that crap the chip manufacturers have been putting into your computer for the past 10 years, so we should give that a shot. I’ll be attending the Boston Summit to see what I can do about this being among all the Shell gang, and rumour has it Gustavo is already doing some crazy experiments with Clutter and Epiphany.
Accessibility
When WebKitGTK+ was accepted for 2.28 the Release Team expressed their trust in that we’d continue our work improving the a11y support in the engine. Me and Igalia will keep our commitment to see this happen, and with 2.28 behind us I’m already looking into it again. Also, I’ll finally meet Joanmarie during the Boston Summit, which I’m sure will be serve to make things move faster and better.
HarfBuzz font backend
Behdad speaks, and we listen. In his own words the Pango backends in WebKitGTK+ and Gecko are either hacks or have to reimplement lots of things that they shouldn’t have, and the right thing to do is to go down one step in the stack and use HarfBuzz directly. This is also a good opportunity to get rid of our multiplicity of font backends, so expect some HarfBuzz love in WebKitGTK+ in the coming months.
Improved HTML5 media support
The final assault on the Flash empire is about to start, and we want to be ready. We already have support for it, but the WebKitGTK+ team (with a new Igalian, Philippe), is already busy fixing all the bugs and implementing all the missing features.
turbocharged libsoup
A lot is on the pipeline for the tasty library. As I mentioned in previous entries, during the 2.27 development cycle Dan realized some of the things we were trying to bolt on on the library would be much easier if some of its internals were revamped, so he put in motion a bold plan to address this. With that in place, a couple of our biggest regressions (HTTP cache and Content-Encoding support) should be easier to kill.
The bugs! The regressions!
Yes, yes, that too! Be sure to report all of them.
Totally awesome to see how far WebKitGTK+ and Epiphany have come! The plans for the future are drool-worthy too. ๐
Well, I’d have loved to test Ephy 2.28 as it seemed to be an awesome release.
However SELinux won’t let me:
https://bugzilla.redhat.com/show_bug.cgi?id=510931
Note that it seems to be a WebKitGTK issue rather than an Epiphany issue, as it also affects Empathy, but only with Adium themes:
https://bugzilla.redhat.com/show_bug.cgi?id=525583
That would be awesome if it could be fixed for 2.30 (or even 2.28.X, but let’s not be too greedy ๐
Any plans for a chrome-like multi-process architecture? What about making at least downloading a separate process?
Multi-process would be nice. Flash has been crashing too many times on me lately ๐
Downloading could be outsourced to nautilus, couldn’t it? That would be clever ๐
It would be nice to see download functions moved to nautilus or implemented in tab just like in opera.
Popup dialog looks annoying.
Pingback: Tweets that mention Iocane powder ยป Blog Archive ยป Together we can rule the Galaxy โ Epiphany 2.28 and WebKitGTK+ 1.1.15.x -- Topsy.com
Awesome… I am especially looking forward to caching and better gstreamer/video support ๐
Besides what you mention it would be great to finally have bookmarking on par with Fx3/Chrome (scalability wise) and the seed extension system also needs some work.
Thanks for all the great work!
It looks flashier than gecko, but also slightly unstable. Happily debian provides debugging symbols
apt-get install epiphany-browser-dbg
Actually It would be really cool if epiphany supported “open link with application”. Then I could use gedit to open any file on the web. Would it be possible to implement this as a plugin or a hidden gconf option?
Downloaded files go to ./.gnome2/epiphany/downloads/. It is not obvious how I should get the files out of this directory. The popup notification was placed below the liferea icon. I found my downloaded files using find and grep, but my mother could not have done that.
I also tried to open settings preferences to change the download directory, but then epiphany crashed (will file bug).
Actually It would have been nice to have the option to “save link as”. Then would have solved my problem too.
Sorry about the rant. It is good to see you making progress with webkit for the benifit of the rest of us. The long term perspectives are indeed drool-worthy.
Awesome work on WebKit/Epi migration. But release notes are way to optimistic about users not noticing difference. After one hour of using 2.28 I’ve already stumbled on:
– middle-click to open URL from clipboard doesn’t work
– http://soup.io script-bookmark doesn’t work
– typing words into URL bar and pressing enter to get them searched on Google doesn’t work.
So three pretty big regression just at the beginning. I’m going to use Epi for few more days, collect my observation and start filling bugs.
@Tomasz:
middle-click to open URL in pasteboard works in master already. The second issue is probably lack of javascript: support, so there’s already a bug about it. And the third one works perfectly OK in 2.28.0, so not sure why you think it does not… open a bug with the exact search you are trying.
@bob
Yeah, the “Open” option in downloads is missing, but it will be reimplemented shortly. And the “Save link as” menu item is already present in master ๐
To everyone else asking about a Chrome-like architecture: that’s a possibility, but it requires a lot of work and would be a major project on itself. A thing we might do to avoid flash taking down the whole browser is to support out-of-process plugin out of the box, which should be easier to implement.
Pingback: Reinout van Schouwen (reinouts) 's status on Sunday, 27-Sep-09 21:42:29 UTC - Identi.ca
It’s great, I’ve been pining for epiphany-webkit for a long time. Somehow fonts look better than with gecko, not sure if it’s my imagination though. A lot of operations are faster. And I can use my bookmarks again – it used to take a long time before my bookmarks drop down (well, I’ve lived without my bookmarks for so long that I’m not sure they’re still useful anymore, but hey).
I’ve noticed a few regressions that have been mentioned before. (webkit’s popup menu, so no “Open in new tab” or “Copy image link”). One small regression that I haven’t seen mentioned yet: when connecting to a website (I suspect during dns lookup or to make the initial http connection), you can’t interrupt loading. If a website is slow to respond, you can’t interrupt it. If that webpage is your homepage, it very quickly becomes annoying.
In any case, even _with_ all these regressions, I think it already is a better browser than before. Thanks for all your hard work.