Category Archives: WebKit

Cross-compiling WebKit2GTK+ for ARM

Published / by mario / 2 Comments on Cross-compiling WebKit2GTK+ for ARM

I haven’t blogged in a while -mostly due to lack of time, as usual- but I thought I’d write something today to let the world know about one of the things I’ve worked on a bit during this week, while remotely attending the Web Engines Hackfest from home:

Setting up an environment for cross-compiling WebKit2GTK+ for ARM

I know this is not new, nor ground-breaking news, but the truth is that I could not find any up-to-date documentation on the topic in a any public forum (the only one I found was this pretty old post from the time WebKitGTK+ used autotools), so I thought I would devote some time to it now, so that I could save more in the future.

Of course, I know for a fact that many people use local recipes to cross-compile WebKit2GTK+ for ARM (or simply build in the target machine, which usually takes a looong time), but those are usually ad-hoc things and hard to reproduce environments locally (or at least hard for me) and, even worse, often bound to downstream projects, so I thought it would be nice to try to have something tested with upstream WebKit2GTK+ and publish it on trac.webkit.org,

So I spent some time working on this with the idea of producing some step-by-step instructions including how to create a reproducible environment from scratch and, after some inefficient flirting with a VM-based approach (which turned out to be insanely slow), I finally settled on creating a chroot + provisioning it with a simple bootstrap script + using a simple CMake Toolchain file, and that worked quite well for me.

In my fast desktop machine I can now get a full build of WebKit2GTK+ 2.14 (or trunk) in less than 1 hour, which is pretty much a productivity bump if you compare it to the approximately 18h that takes if I build it natively in the target ARM device I have :-)

Of course, I’ve referenced this documentation in trac.webkit.org, but if you want to skip that and go directly to it, I’m hosting it in a git repository here: github.com/mariospr/webkit2gtk-ARM.

Note that I’m not a CMake expert (nor even close) so the toolchain file is far from perfect, but it definitely does the job with both the 2.12.x and 2.14.x releases as well as with the trunk, so hopefully it will be useful as well for someone else out there.

Last, I want to thanks the organizers of this event for making it possible once again (and congrats to Igalia, which just turned 15 years old!) as well as to my employer for supporting me attending the hackfest, even if I could not make it in person this time.

Endless Logo

Attending the Web Engines Hackfest

Published / by mario / 1 Comment on Attending the Web Engines Hackfest

webkitgtk-hackfest-bannerIt’s certainly been a while since I attended this event for the last time, 2 years ago, when it was a WebKitGTK+ only oriented hackfest, so I guess it was a matter of time it happened again…

It will be different for me this time, though, as now my main focus won’t be on accessibility (yet I’m happy to help with that, too), but on fixing a few issues related to the WebKit2GTK+ API layer that I found while working on our platform (Endless OS), mostly related to its implementation of accelerated compositing.

Besides that, I’m particularly curious about seeing how the hackfest looks like now that it has broaden its scope to include other web engines, and I’m also quite happy to know that I’ll be visiting my home town and meeting my old colleagues and friends from Igalia for a few days, once again.

Endless Mobile logoLast, I’d like to thank my employer for sponsoring this trip, as well as Igalia for organizing this event, one more time.

See you in Coruña!

Importing include paths in Eclipse

Published / by mario / 1 Comment on Importing include paths in Eclipse

First of all, let me be clear: no, I’m not trying to leave Emacs again, already got over that stage. Emacs is and will be my main editor for the foreseeable future, as it’s clear to me that there’s no other editor I feel more comfortable with, which is why I spent some time cleaning up my .emacs.d and making it more “manageable”.

But as much as like Emacs as my main “weapon”, I sometimes appreciate the advantages of using a different kind of beast for specific purposes. And, believe me or not, in the past 2 years I learned to love Eclipse/CDT as the best work-mate I know when I need some extra help to get deep inside of the two monster C++ projects that WebKit and Chromium are. And yes, I know Eclipse is resource hungry, slow, bloated… and whatnot; but I’m lucky enough to have fast SSDs and lots of RAM in my laptop & desktop machines, so that’s not really a big concern anymore for me (even though I reckon that indexing chromium in the laptop takes “quite some time”), so let’s move on :-)

However, there’s this one little thing that still bothers quite me a lot of Eclipse: you need to manually setup the include paths for the external dependencies not in a standard location that a C/C++ project uses, so that you can get certain features properly working such as code auto-completion, automatic error-checking features, call hierarchies… and so forth.

And yes, I know there is an Eclipse plugin adding support for pkg-config which should do the job quite well. But for some reason I can’t get it to work with Eclipse Mars, even though others apparently can use it there for some reason (and I remember using it with Eclipse Juno, so it’s definitely not a myth).

Anyway, I did not feel like fighting with that (broken?) plugin, and in the other hand I was actually quite inclined to play a bit with Python so… my quick and dirty solution to get over this problem was to write a small script that takes a list of package names (as you would pass them to pkg-config) and generates the XML content that you can use to import in Eclipse. And surprisingly, that worked quite well for me, so I’m sharing it here in case someone else finds it useful.

Using frogr as an example, I generate the XML file for Eclipse doing this:

  $ pkg-config-to-eclipse glib-2.0 libsoup-2.4 libexif libxml-2.0 \
        json-glib-1.0 gtk+-3.0 gstreamer-1.0 > frogr-eclipse.xml

…and then I simply import frogr-eclipse.xml from the project’s properties, inside the C/C++ General > Paths and Symbols section.

After doing that I get rid of all the brokenness caused by so many missing symbols and header files, I get code auto-completion nicely working back again and all those perks you would expect from this little big IDE. And all that without having to go through the pain of defining all of them one by one from the settings dialog, thank goodness!

Now you can quickly see how it works in the video below:


VIDEO: Setting up a C/C++ project in Eclipse with pkg-config-to-eclipse

This has been very helpful for me, hope it will be helpful to someone else too!

On Linux32 chrooted environments

Published / by mario / 2 Comments on On Linux32 chrooted environments

I have a chrooted environment in my 64bit Fedora 22 machine that I use every now and then to work on a debian-like 32bit system where I might want to do all sorts of things, such as building software for the target system or creating debian packages. More specifically, today I was trying to build WebKitGTK+ 2.8.3 in there and something weird was happening:

The following CMake snippet was not properly recognizing my 32bit chroot:

string(TOLOWER ${CMAKE_HOST_SYSTEM_PROCESSOR} LOWERCASE_CMAKE_HOST_SYSTEM_PROCESSOR)
if (CMAKE_COMPILER_IS_GNUCXX AND "${LOWERCASE_CMAKE_HOST_SYSTEM_PROCESSOR}" MATCHES "(i[3-6]86|x86)$")
    ADD_TARGET_PROPERTIES(WebCore COMPILE_FLAGS "-fno-tree-sra")
endif ()

After some investigation, I found out that CMAKE_HOST_SYSTEM_PROCESSOR relies on the output of uname to determine the type of the CPU, and this what I was getting if I ran it myself:

(debian32-chroot)mario:~ $ uname -a
Linux moucho 4.0.6-300.fc22.x86_64 #1 SMP Tue Jun 23 13:58:53 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

Let’s avoid nasty comments about the stupid name of my machine (I’m sure everyone else uses clever names instead), and see what was there: x86_64.

That looked wrong to me, so I googled a bit to see what others did about this and, besides finding all sorts of crazy hacks around, I found that in my case the solution was pretty simple just because I am using schroot, a great tool that makes life easier when working with chrooted environments.

Because of that, all I would have to do would be to specify personality=linux32 in the configuration file for my chrooted environment and that’s it. Just by doing that and re-entering in the “jail”, the output would be much saner now:

(debian32-chroot)mario:~ $ uname -a
Linux moucho 4.0.6-300.fc22.x86_64 #1 SMP Tue Jun 23 13:58:53 UTC 2015
i686 i686 i686 GNU/Linux

And of course, WebKitGTK+ would now recognize and use the right CPU type in the snippet above and I could “relax” again while seeing WebKit building again.

Now, for extra reference, this is the content of my schroot configuration file:

$ cat /etc/schroot/chroot.d/00debian32-chroot
[debian32-chroot]
description=Debian-like chroot (32 bit) 
type=directory
directory=/schroot/debian32/
users=mario
groups=mario
root-users=mario
personality=linux32

That is all, hope somebody else will find this useful. It certainly saved my day!

WebKitGTK+ Hackfest 2013: The Return of the Thing

Published / by mario

The WebKitGTK+ Hackfest 2013As many other WebKitGTK+ hackers (30 in total), I flew last Saturday to A Coruña to attend the 5th edition of the WebKitGTK+ Hackfest, hosted once again by Igalia at their premises and where people from several different affiliations gathered together to try to give our beloved port a boost.

As for me, I flew there to work mainly on accessibility related issues, making the most of the fact that both Joanie (Orca maintainer) and Piñeiro (ATK maintainer) would be there too, so it should be possible to make things happen faster, specially discussion-wise.

And turns out that, even if I feel like I could have achieved more than what I actually did (as usual), I believe we did quite well in the end: we discussed and clarified things that were blocking the mapping of new WAI-ARIA roles in WebKitGTK+, we got rid of a bunch of WebKit1-specific unit tests (Joanie converted them into nice layout tests that will be run by WebKit2GTK+ too), we got a few new roles in ATK to be able to better map things from the web world and and we fixed a couple of issues in the way too.

Of course, not everything has been rainbows and unicorns, as it seems that one of the patches I landed broke the inspector for WebKit2GTK+ (sorry Gustavo!). Fortunately, that one has been rolled out already and I hope I will be able to get back to it soon (next week?) to provide a better patch for that without causing any problem. Fingers crossed.

In the other hand, my mate Brian Holt joined us for three days too and, despite of being his first time in the hackfest, he got integrated pretty quickly with other hackers, teaming up to collaborate in the big boost that the network process & multiple web processes items have went through during the event. And not only that, he also managed to give a boost to his last patch to provide automatic memory leak detection in WebKitGTK+, which I’m sure it will be a great tool once it’s finished and integrated upstream.

Anyway, if you want more details on those topics, or anything else, please check out the blog posts that other hackers have been posting these days, specially Carlos’s blog post, which is quite extensive and detailed.

Samsung LogoOf course, I would like to thank the main sponsors Igalia and the GNOME Foundation for making this thing happen again, and to my employer Samsung  for helping as well by paying our trips and accommodation, as well as the snacks and the coffee that helped us stay alive and get fatter during the hackfest.

Last, I would like to mention (in case anyone reading this wondered) that it has indeed felt a bit strange to go the city where I used to live in and stay in a hotel, not to mention going to the office where I used to work in and hang around it as a visitor. However, both my former city and my former colleagues somehow ensured that I felt as “at home” once again, and so I can’t do anything about it but feeling enormously grateful for that.

Thank you all, and see you next year!

Greppin’ in the past with git

Published / by mario / 4 Comments on Greppin’ in the past with git

It seems that one can never stop learning new things with git, no matter for how long you’ve been using it (in my case, I’m a proud git user since 2008), because today I added a new trick to my toolbox, that already proved to be quite useful: “grepping” files in a git repository, as you would do it with git grep, but using a commit-id to limit the search to a specific snapshot of your project.

In other words, I found that it’s possible to do things like, say, grep files to search for something in your repository considering how it was, say, some commits ago.

This is the “magical” command:

    git grep <search-params> <tree-id>

This is what I get if I try to search for updateBackingStore() in my local clone of WebKit, as if my current branch was “50 commits older” than what it actually is:

$ git grep updateBackingStore HEAD~50
0ae236137d560da6ca889a826a8f3d023364a669:AccessibilityObject.cpp:void AccessibilityObject::updateBackingStore()
0ae236137d560da6ca889a826a8f3d023364a669:AccessibilityObject.h:    void updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:AccessibilityObject.h:inline void AccessibilityObject::updateBackingStore() { }
0ae236137d560da6ca889a826a8f3d023364a669:atk/WebKitAccessibleUtil.h:        coreObject->updateBackingStore(); \
0ae236137d560da6ca889a826a8f3d023364a669:atk/WebKitAccessibleUtil.h:        coreObject->updateBackingStore(); \
0ae236137d560da6ca889a826a8f3d023364a669:atk/WebKitAccessibleWrapperAtk.cpp:    coreObject->updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:ios/WebAccessibilityObjectWrapperIOS.mm:    m_object->updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:ios/WebAccessibilityObjectWrapperIOS.mm:    m_object->updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:mac/WebAccessibilityObjectWrapperBase.mm:    // Calling updateBackingStore() can invalidate this element so self must be retained.
0ae236137d560da6ca889a826a8f3d023364a669:mac/WebAccessibilityObjectWrapperBase.mm:    m_object->updateBackingStore();

I don’t know about you, but I find this quite useful for me to answer questions such as “Where was this function being used in commit X?”, and things like that.

Anyway, you might have noticed that I mentioned <tree-id> in the recipe instead of <commit-id>, yet I used HEAD~50 in the example, which is actually a commit-id. And still works.

And the short explanation, without trying to explain here all the different kind of data types that git keeps internally for every repository (mainly commitstrees and blobs), is that git is smart enough to find the right tree-id associated to a given commit-id by just considering the current path inside the repository and the tree-id associated to the top directory for a given commit.

But how to know that tree-id myself in case I want to? Easy, just pretty print the full information of the commit object you’re interested in, instead of only seeing the abbreviated version (what you usually see with git show or git log:

$ git cat-file -p HEAD~50
tree 0ae236137d560da6ca889a826a8f3d023364a669
parent bdb7a7949a29988da3fe50a65d6c694d5084d379
author [...]

See that tree thing in the first line? That’s the tree-id that git needs for grepping, which as you can see can be easily extracted from a particular commit. Actually, you could get easily the tree-id for any subdirectory from this point, by using the git ls-tree command:

$ git ls-tree 0ae236137d560da6ca889a826a8f3d023364a669
100644 blob 3fe2340c9614e893f0dfeb720f23773bbf1ea076	.dir-locals.el
100644 blob 741c4d53b5a0338cf36900a283e89408d0f9d457	.gitattributes
100644 blob f45a975762be9a429aa971c18da01b433c559553	.gitignore
100644 blob d571aa28ea86c14c7880533bf3ba68e9ef4b3c81	.qmake.conf
100644 blob 10f85055ae9f3823f0d20808599f644c18af7921	CMakeLists.txt
100644 blob 5eb66e7bcbc7543eb3a4dbf183a9043545776659	ChangeLog
100644 blob 7dbe9d2e0029bab47b8b2b22065a1032ecfe4434	ChangeLog-2012-05-22
040000 tree d42a0b3121ed7993cfd250426d20472769760f87	Examples
100644 blob 78d89e5c70ad56c38b0c25e7705d42fa380c4ee0	GNUmakefile.am
040000 tree 4a9e87fc1f35efa1349a18b1df694530c981c57e	LayoutTests
100644 blob 14e33157011157797dac62c494bac0bf254d7c2f	Makefile
100644 blob ee723d830dea51d1ce9e2d1ad8c985eeca2d4f3f	Makefile.shared
040000 tree 20c763d6a4e8749ad9e041e8372e9f47dc722f45	ManualTests
040000 tree 660d88b926cf618ab9e1612b8e2a3e97b15dbcbe	PerformanceTests
040000 tree fbf9703d3e9a9e4cf2ff10817c99ba3a5de87410	Source
040000 tree 346110c441a674334f5f56ef42b9dd40def89c76	Tools
040000 tree 262cb11d9b491be35daee570f9b825bce5715579	WebKit.xcworkspace
040000 tree b9e48a7a24b4973b253ee14053808b40d67c94aa	WebKitLibraries
040000 tree adce37b690957abdd21d2dd8ff77302c5a5a9071	Websites
100755 blob befd429487fc5ac9bb3494800f4eeaef1e607663	autogen.sh

And of course, “navigating” with more calls to git ls-tree you could also get the tree-id for a specific subdirectory, in case you wanted to constraint the search to that specific path of your repo.

However, considering that git is so good at translating a commit-id into a tree-id, my personal recommendation is that, instead, you first cd into the path you want to focus the search in, and then let git  do its “magic” by just using the git grep <search-params> <tree-id> command.

So that’s it. Hope you find this useful, and please do not hesitate to share any comment or suggestion you might have with regard to this or any other “git trick” you might know.

I honestly love using git so much that sometimes I wonder if coding is not just a poor excuse to use git. Probably not, but the thing is that I can not imagine my life without it anymore. That’s a fact.

Goodbye Pango! Goodbye GAIL!

Published / by mario / 2 Comments on Goodbye Pango! Goodbye GAIL!

As I mentioned in my previous post before GUADEC, I’ve been putting some effort lately on trying to improve the accessibility layer of WebKitGTK+, as part of my work here at Samsung, and one of the main things I’ve worked on was the removal of the dependency we had on Pango and GAIL to implement the atk_text_get_text_*_offset() family of functions for the different text boundaries.

And finally, I’m really happy to say that such a task is complete once and for all, meaning that now those functions should work as well or as bad on WebKit2GTK+ as they do in WebKitGTK+, so the weird behaviour described in bug 73433 is no longer an issue. You can check I’m not lying by just taking a look to the commit that removed both all trace of Pango and GAIL in the code, as well as and the one that removed the GAIL dependency from the build system. And if you want more detail, just feel free to check the whole dependency tree in WebKit’s bugzilla.

This task has been an interesting challenge for me indeed, and not only because it was one of the biggest accessibility related tasks I’ve worked on in WebKitGTK+ since late 2012 (so I needed to get my brain trained again on it), but also because reimplementing these functions forced me to dive into text editing and accessibility code in WebCore as I never did before. And it’s so cool to see how, despite of having to deal eventually with the frustrating feeling of hitting my head against a wall, at the end of the day it all resulted on a nice set of patches that do the work and help advance the state of the ATK based accessibility layer in WebKitGTK+ forward.

Anyway, even though that is probably the thing that motivated me to write this blog post, that was not the only thing that I did since GUADEC (which has been a blast, by the way):

On the personal side, I’ve spent two lovely weeks in Spain on holidays, which was the biggest period of time I’ve been outside of the UK since I arrived here, and had  an amazing time there just “doing nothing”(tm) but lying around on the beach and seeing the grass grow. And there is not much grass there anywhere, so you can imagine how stressful that life was… it was great.

In the other hand, on the professional side, I’d say that one of the other big things that happened to me lately was that I finally became accepted as a WebKit reviewer, meaning that now I can not only help breaking the Web, but also authorize others to do it so. And while agree that might be fun in some way, it probably would not be very cool, so forgive me if I try instead to do my best to help get exactly the opposite result: make things work better.

And truth to be told, this “upgrade” came just with perfect timing, since these days quite some work is being done in the accessibility layer for both the WebKitGTK+ and the WebKitEFL ports thanks also to my mates Denis NomiyamaAnton ObzhirovBrian Holt and Krzysztof Czech from Samsung, and that work would ideally need to be reviewed by someone familiar with the ATK/AT-SPI based accessibility stack. And while I’m still by far not the most knowledgeable person in the world when it comes to those topics, I believe I might have a fairly well knowledge about it anyway, so I assume (and hope) that my reviews will certainly add value and help with those specific pieces of work.

And as a nice plus, now I can finally “return the favour” to the only accessibility reviewer WebKit had until now (Chris Fleizach) by helping reviewing his patches as well, in a similar fashion to what he has been tirelessly doing for me for the last 3 years and a half. Yay!

To finish , I’d like to get back again to the original topic of this post and say a big “thank you” to everyone who helped me along the way with the removal of Pango and GAIL from the ATK specific code. Special thanks go to those who spend time performing the code reviews, as it’s the case of Martin, Gustavo and Chris. I wouldn’t be writing this post otherwise.

Thanks!

I’m going to GUADEC!

Published / by mario / 1 Comment on I’m going to GUADEC!

I'm attending GUADECOne year again GUADEC is approaching and, also again, I’m very happy to say that I’ll be there as well this time, even if I have to recognize it was not on my plans for this year, at least not initially.

And the reason why it was not initially in my plans was mainly because I’ve been already through quite some changes during these past months year, and my family just came over to the UK two months ago. This means that, even I already arrived by the beginning of the year, we just started to settle here as a family a few weeks ago. So in that context, I didn’t feel like leaving them alone for one week already now, it definitely would look like a “wrong management of priorities” to me.

However, it turns out that my wife and kids won’t be here anyway during the first week of August and, on top of that, Samsung has been so kind to sponsor this trip just based on the simple fact that I’m part of the GNOME community. So, I certainly can no longer find a single reason not to go and spend 7 amazing days in Brno, meeting people that I normally see only in conferences (and this time that group of people will be bigger than ever, since my former mates from Igalia are now also included there), while attending to what it seems to be a very appealing event.

Also, I will try to make the most of the trip to do some work during the different hackfests and BoFs that are already planned, which special focus in the one about accessibility, of course. As a personal goal, I expect to have the chance to move forward some work I’ve been doing lately in the WebKitGTK+ a11y world, such as getting rid of the nasty dependency on Pango/Gail we still have there, something I’ve been already working on for some time now, and which I expect it will be fixed soon, hopefully before GUADEC, although time will tell.

Once that it’s fixed, WebKit2GTK+ based apps should recover the ability to properly expose text through the atk_text_get_text_*_offset() family of functions for different text boundaries, which means that ATs (e.g. the Orca screen reader)  will be able to properly allow again line-by-line navigation when in caret browsing mode. And, as you can imagine, this is quite a big problem these days, since WebKit2GTK+ that has become the default backend for some core apps such as the Epiphany browser with the GNOME 3.8 release, so fixing this is like a high priority now, I’d say.

Samsung LogoAnyway, I’m starting to write too much (as usual) for what it was going to be a short “I’m going to GUADEC” blog post, so I will stop right now, although not without first thanking Samsung for sponsoring this my first trip to the Czech Republic.

See you all in three weeks!

WebKit Contributors Meeting 2013

Published / by mario / 2 Comments on WebKit Contributors Meeting 2013

It turns out I’m writing this post at 6:00 AM in the morning from a hotel instead of doing it at a more reasonable time from my comfy home or a nice cafeteria. That’s already quite a new thing by itself, and the reason for that is not that I became crazy or something, but the fact that I’m completely jet-lagged in California right now in order to attend my second WebKit Contributors Meeting (my first time was in 2011), this time as part of the Samsung team in the UK R&D center, together with my mate Anton Obzhirov.

With regard to that, it has been a very interesting experience so far where I could meet new people I still haven’t had the chance to see in real life yet (e.g. my mates from other Samsung R&D centers or some guys from Apple I didn’t have the chance to meet in person before), as well as chat again with some friends and former mates that I haven’t seen for a while, such as Martin, Xan and Philippe from Igalia, Byungseon from LG, Nayan from Motorola or Gustavo from Collabora to mention some of them. It’s strange, and at the same time wonderful, how easily you can catch up on conversations with people that you barely see once a year (or even less) and mainly in conferences, and definitely one of my favourite parts of attending these kind of events, to be honest.

Also, from a less social point of view, I have to say I found very interesting the sessions I’ve attended so far, specially the one about “managing the differences between ports”, although the one about “build systems” was quite interesting too. Not sure how far we are yet in the WebKitGTK+ port from realistically switching to some kind of commonly agreed build system (cmake?), but at least it’s a good start to agree on the fact that it would be an interesting move and now that some people pushing for it.

My only regret about this first day is that I missed Hyatt‘s talk about pagination due to some health issues I’m experimenting while in California, mostly due to the extremely hot and dry weather (anything over 25 Celsius is “unbearable hot” for me), which is causing me a little bit of cough, sore throat and fever, all well mixed with the jet lag to make it a perfect “welcome pack” to the meeting. Fortunately, I got some “interesting” medicines that seem to have relieved a bit the pain and I could attend the rest of the sessions without much trouble, other than some occasional coughing. Not bad.

By the way, for those of you who were not lucky enough to attend the meeting but are anyway interested in the topics being discussed here, make sure you check the main TRAC page for the meeting, where you can also find transcripts for most of the sessions.

As for today, some more sessions will take place as well as a couple of hackathons so I expect it to be very interesting as well. Also I hope I can find some time too to work a bit on my patches to remove the nasty dependency on pango we have in WebKitGTK+ accessibility code, which is preventing us to have proper caret navigation in WebKit2GTK+ based browsers, as well as to discuss possible ways in which our lab could collaborate more actively upstream. Seems a promising day already!

Last (but not least), and in a completely unrelated and super-off-topic way, I would like to tell the world that I’m extremely happy for the fact that next week will be the end of my “lonely existence in the UK”, finally. After 4 months of living away from my family with just some flash trips from Friday to Sunday (every 2 weeks), I’m once and for all travelling on Thursday to my home town with a one way plane ticket to do some final arrangements, put everything (family included!) in the car and travel to Santander, where we’ll be taking a ferry that will take us to the Portsmouth (southern coast of England), from where we will just drive to the UK in order to start our new life, all together again.

It has been quite hard for us to live this way for so long, but I think in the end we managed to handle the situation quite well, and now it seems all our efforts are already paying off because things seem to be finally fitting in the right places: we have a lovely house, we have a place in a nearby public school for my oldest kid to start on September, most of the needed paperwork seems to be done and we already moved all our stuff from Spain (lots of toys!), which is now waiting to be used in our new place.

I really can’t wait to live again in the noisy and chaotic atmosphere that two kids can so easily create around them. Even if that means it will probably drive me crazy every now and then and that I won’t sleep that well sometimes.

Yes. Even considering that.

Accessibility in [WebKit]GTK+

Published / by mario / 8 Comments on Accessibility in [WebKit]GTK+

This past week I’ve spent some time explaining to my mates at Samsung the basics about how accessibility works and is implemented in WebKitGTK+. I realized, yet again, of how messy and confusing everything can be the first time you encounter these things. After all, WebKit is quite a complex project already and accessibility is not a simple matter either.

In order to help them better understand this topic, I wrote a summary to have as reference that explains in my own words which the main pieces of the whole puzzle are, and how they relate to one another. In my experience, it’s not always easy to understand the big picture quickly, and I think this kind of documentation can be quite useful for anyone willing to contribute to accessibility in WebKitGTK+. At least it would have been useful for me when I started working on this. I only regret not having written it before, but better late than never, right?

So let’s begin then. I will start by talking about accessibility-only stuff, which are basically common to any accessible application based in GTK+. Then I will explain the bits specific to WebKitGTK+ and how they fit in the picture.

Accessibility in GTK+ applications

The parts, or “actors”, involved in any GTK+ application from an accessibility point of view are:

  • Assistive Technologies (ATs)
  • AT-SPI (Assistive Technology Service Provider Interface)
  • ATK (Accessibility ToolKit)
  • ATK <-> AT-SPI bridge
  • GTK+
  • GTK’s Accessibility Implementation

Accessibility in GTK+ applications

Now let’s describe all those points, one by one:

Assistive Technologies (ATs):

ATs are applications whose main purpose is to facilitate access and/or interaction with certain bits of information interesting from an accessibility related point of view, exposed by other applications. This access/interaction can be primarily output based. For instance the Orca screen reader is an AT which provides access via text to speech and/or refreshable braille to on-screen information exposed by editors, browsers, mail agents and other applications.

Other ATs are primarily input based, allowing the user to interact with the exposed applications by executing certain actions over them (e.g. clicking on a exposed link), so it’s not just about “consuming” information. Normally, ATs are called the clients and the applications exposing information the servers, as in the end it’s actually an implementation of a typical client/server architecture.

AT-SPI (Assistive Technology Service Provider Interface):

Set of interfaces that Assistive Technologies (the clients) understand and use to inspect and interact with the accessible content exposed by applications in Linux environments. At some point, “someone” has to provide actual AT-SPI objects (linked together forming a AT-SPI hierarchy) implementing several of those interfaces (depending of the type of object) so ATs can “see them”.

This is the job of the AT-SPI registry, a daemon which takes care of maintaining a hierarchy of AT-SPI objects for every single accessible application in the system, in a centralized way, so ATs can interact with them. It is worth mentioning that the parent/children relationships in that hierarchy are modelled in terms of D-Bus, so different AT-SPI objects can belong to different processes.

ATK (Accessibility ToolKit):

The toolkit used by GTK+ applications to expose accessible representations of the toolkit’s objects, along with appropriate interfaces, on the side of the applications exposing content (the servers). This representation is an almost a 1:1 match with the objects and interfaces defined by AT-SPI (that is, almost).

The main difference when it comes to understanding its place in the puzzle is that AT-SPI is what clients (ATs) understand, and that is not process-bounded (see previous point). ATK, in contrast, is what servers implement to expose accessible information, and it is process-bounded. Thus the parent/children relationships in the ATK hierarchy are modelled by actual references (pointers) between objects living in the same process.

ATK <-> AT-SPI bridge:

The glue that makes sure there’s a mapping between the ATK hierarchy living in the server process and the AT-SPI hierarchy held by the AT-SPI registry. Such a bridge is implemented in terms of D-Bus too, as it needs to communicate with the registry whenever something needs to be updated there, as well as when the server needs to react to external actions coming from ATs (e.g. perform the default action for an object).

GTK+:

The widgets toolkit normally used by applications embedding WebKitGTK+. Explaining what GTK+ is beyond the scope of this post, so I will assume you already know what it is.

GTK’s Accessibility Implementation:

Provides ATK objects implementing different ATK interfaces for every widget from the GTK+ library, and uses the ATK <-> AT-SPI bridge to communicate with the AT-SPI registry. This means that if you use standard GTK+ widgets only, your application will be accessible out-of-the-box. On the contrary, should you use custom widgets, you’ll probably have to write custom ATK objects implementing the proper ATK interfaces to make them accessible too.

So that’s all so far, when it comes to GTK+ applications. Check the following diagram for a more detailed look at all these hierarchies for a hypothetical GTK+ application exposing information and a screen reader accessing it:

Accessibility in GTK+ applications: a specific exampleAs you can see, there’s an ATK tree matching the GTK+ hierarchy, and another AT-SPI tree matching the ATK one. Finally, the screen reader accesses the information through that AT-SPI tree, as explained above.

Accessibility in WebKitGTK+

Now that we already understand the basics of accessibility in GTK+ applications, let’s add the bits specifically related to WebKitGTK+. Namely:

  • WebCore’s Accessibility Objects
  • WebKitGTK+ (ATK) wrappers
  • WebKit2GTK+ specific details

Again, a picture is usually better than just text, so here you have one too:

Accessibility in WebKitGTK+

In order to clarify it a bit more before explaining each point, let’s just say that  you’ll have to look in the dashed box named WebCore accessibility world, where the hierarchy on the left (red & orange) represent the WebCore Accessibility objects, while the one on the right (the green one) represents the WebKitGTK+ ATK wrappers.

With this in mind, let’s examine these three points in more depth:

WebCore Accessibility objects:

Similar to GTK’s Accessibility Implementation, WebCore‘s accessibility objects are the implementation of an independent hierarchy exposing accessibility related information for objects present in a web page. As the mission of accessibility in WebKit is to expose information to users that are normally being rendered in the screen (as well as some other information that might be hidden to regular users), there is a tight relationship between this hierarchy and other ones in WebKit, such as the DOM tree and the Render Objects tree.

This layer is meant to be platform-agnostic, so you won’t find much WebKitGTK+ specific stuff here. Instead, you will find the implementation of the accessibility related specifications published by the W3C‘s Web Accessibility Initiative (WAI), such as WAI-ARIA.

WebKitGTK+ ATK wrappers:

An ATK-based implementation of an accessibility hierarchy where every ATK object will take care of wrapping the proper accessibility object from WebCore, as well as implementing the proper ATK interfaces depending on the situation (e.g. the role of the WebCore accessibility object, some properties coming from the associated Render Object…).

The ATK hierarchy created here is connected with the ATK hierarchy from the embedding application (normally a GTK+ app) by setting the root ATK object in this tree (normally representing DOM‘s root element) as the child of the leaf ATK object in the tree coming from the embedding application (normally the GtkWidget containing the WebView).

As is the case with any other regular GTK+ application, this ATK hierarchy will finally be seen by ATs thanks to the translation that the ATK <-> AT-SPI bridge will do for us, making the whole ATK tree from the WebKitGTK+ based application (from the top level GTK+ window down to the deepest accessibility object inside WebCore) available to the AT-SPI registry by means of D-Bus.

WebKit2GTK+ specific details:

I already talked about this in previous posts, so I will focus here just on commenting the main difference compared to the generic case for WebKitGTK+ described earlier (see previous diagram above):

WebKit2GTK+ implements a split-process model, where the  high level API belongs to one process (the UI process) while the core logic of the web engine lives in another one (the Web process).

From an accessibility point of view, this means that the full hierarchy of ATK objects we had before is also split in two parts: some accessibility objects are now in the UI process and the rest of them will be in the Web process.

To be more specific, we’ll find the following objects in each process:

As I explained previously, these two ATK hierarchies will be seen as a single accessibility hierarchy by ATs thanks to the “magic” of AtkPlug and AtkSocket classes, which takes care of exposing everything together in a single AT-SPI tree. And remember that such a tree is modelled by means of D-Bus, so it does not matter that things are actually in different processes.

Thus, since ATs just  understand AT-SPI, they will see The Right Thing ™ as in the previous case where we have one single process. See the following diagram for a more visual explanation of this:

Accessibility in WebKit2GTK+

Wrapping up

So that’s it. At the end the post turned out to be longer than what I was expecting, as my initial idea was to publish the stuff I wrote internally at Samsung this week, but ended up extending it quite a lot!

At least I hope this will be helpful for anyone willing to contribute to accessibility, either in WebKitGTK+ or in a more general way.

After all, most of the stuff I talked about here applies to  every accesible GTK+ application: Assistive Technologies (ATs)AT-SPIATK, the ATK <-> AT-SPI bridge

Last, I would like to thanks Joanmarie Diggs from Igalia for her help with this blog post. One certainly feels more confident writing a long article like this one about a very specific topic when you have one of the most experienced persons on the matter reviewing it!

My first week at SERI

Published / by mario / 9 Comments on My first week at SERI

So, after almost 3 months of “holidays”, I’ve finally started working on my new job this Tuesday in Samsung Electronics Research Institute UK (aka SERI), where I’ll join a team mainly working in A/V and DTV related stuff while, at the same time, I’ll keep contributing to WebKit and WebKitGTK+.

Samsung Smart TV Unveils New Smart HubAs you can imagine, being the first week means that I mostly spent my time learning a lot of stuff about my new job and the tools I’d be using, as well as setting up my development environment and getting to know my colleagues and the things we’ll be working on.

But for the time being I have to say that my first impression has already been very positive and that I’m enthusiastically looking at the future and what it’s going to be next. Surely it will be a very different experience compared to what I was used to, but in a way that’s precisely what I was looking for, and so that’s why I feel very optimistic and motivated about it.

Also, and besides work related stuff, being a new resident in the UK also means that I had to spend some time doing some additional things, such as creating a bank account, getting a UK-based SIM card and starting to look for a place that should become our permanent residence in 2-3 months time, once my wife and my children move as well to the UK (they’re still in Spain), hopefully before Easter. Fortunately, being a EU citizen simplifies a lot the whole thing of coming here to work, since I don’t need any VISA or the like. Just my Spanish ID and/or Passport are more than enough.

Anyway, I’ve just arrived in the UK on Monday and started working on Tuesday (yeah, I love having big margins) so still much to do left, but I’m already on my way so it’s a matter of time that we are settled here, and that we start living the “English adventure” all together again.

But in the meanwhile we’ll have to live with me visiting them every 2-3 weeks and the typical audio/video conference tools.

Can’t wait!

Moving On

Published / by mario / 14 Comments on Moving On

Two months ago it was an important day for me. It was the day that I finally told my partners at Igalia that I’d be leaving the company, after almost seven years. It hasn’t been an easy decision to make and so this hasn’t been an easy post to write either… yet one I’d like to write anyway.

But let’s push the rewind button for a moment now…

I’ve joined Igalia on November 2005, initially as a trainee while I was finishing my studies of Computer Science Engineering, and got quickly hooked by the company, the people that was part of it back then and the kind of project they were trying to build.

Igalia as a company is one of a kind, you can be sure of it, and I felt enormously lucky for having found it and having been granted with the privilege of being part of it. And best of all… it happened to have its main office in my own town! I just couldn’t believe it…

I even still recall now how many mates of mine in the Faculty were telling me, back in the days of the University, things like “that Linux thing you like so much is not worth it”, “forget about Open Source, you won’t ever make a living out of it” or even “well, maybe there’s a chance for you to work on that, but it’s definitely not going to happen here”.

I have to say I never believed much in any of those statements (well, maybe a bit the last one), but I swear I couldn’t have ever imagined that I’d be able to prove all of them wrong at the same time without even having to move out of the country, let alone the town.

It was too good to be true. But it was true and real… it definitely was real.

And turns out that what started as a 3-month internship in late 2005, became my first permanent job (and the only one so far) when I became a regular employee on February 2006, to finally become a partner of the company in 2010. Not bad.

I worked on many different projects across all these years, from system administration tasks and pure web development to application development over the GNOME and the Maemo platforms, to end up working on what it probably became the most challenging and interesting thing I’ve ever worked on: the WebKit project and, more specifically, the WebKitGTK+ port.

Additionally, I also met a lot of awesome people while there, both inside Igalia and outside (e.g. at conferences), in some cases  becoming closer to “actual friends” than to “just work mates”, which is yet another great thing I will always feel lucky and grateful for.

In other words, I grew up there, both at the professional and the personal level, and I feel endlessly grateful for that. I’m sure my life wouldn’t have been the same now without that stage in my life, so I don’t have more than good words and thoughts about it.

However, and even if I still think Igalia is an awesome place to be part of, I’ve been lately feeling like I needed a change, to try something new, to move on…

I’m not sure about how much that could be related to the fact that my life is now quite different than seven years ago, and that perhaps my priorities could have shifted now I have my own family, but the fact is that at some point I very clearly saw that I would need to try something else, to change some things and patterns in my life, kind of a “fresh restart”.

And after so much thinking, I suddenly realized such a  change couldn’t ever happen if I stayed in Igalia, since it would probably require that the company stopped being as it is in some ways. And that’s something I don’t think I should ask for “just because I felt that way”. That would be too selfish, don’t you think?

So I made the only decision I thought it made sense: to quit.

Sure it was hard, and even tough at some moments, to make such a decision. But once I made it for real, I have to say I felt very well about it, as if everything was making sense once again, as if the puzzle I was trying so hardly to solve was finally complete.

In any case, this doesn’t mean I want to work on something completely different either. In my lollipop world, my plan is to keep working around the Open Source world as much as possible, hopefully also around GNOME and WebKit, the two platforms I learned to love during these years. Well, actually for the case of GNOME I must say it’s a platform I already loved before joining Igalia, but I can’t deny that being part of that company played a major role to help me get more involved on it, so that’s why I think it deserves some credit.

Fortunately, I’m a lucky guy and I can already say that, just two months after making that decision and starting looking for new opportunities, I already found a job where I think I’ll be able to keep working in what I love (see paragraph above) while, at the same time, being also able to try something different and new compared to what I’ve done so far.

Additionally, I think this new job will also help me find answers to the questions that have been crossing my mind lately, let alone learning new stuff… I’m sure I’ll learn a lot of new stuff as well, something I already can’t wait for.

Anyway, I won’t start working there until January, so let’s go step by step.

First I needed to write this post to tell the world about my new situation (check). Second, I need to use these “two months in nowhere” to re-organize my life and arrange many different things related to the short-term (work in progress). Finally, I’ll start that new stage in my life and finally announce here where I’m going to, something I’d rather keep for another post.

Surely I know all this will mean big challenges for both me and my family (we’ll be moving abroad, to begin with), but those are challenges we’re willing to face and can’t wait for. In a way, I kind of feel like I did 7 years ago right before joining Igalia, when I just finished my studies at the University and still had no clue what I was going to do with my life. Back then, the future looked uncertain and full of opportunities at the same time, and if I now look backwards I can clearly see it was even better than what I’ve would ever have expected. Really.

And you know what? That’s exactly how I feel right now, and that’s a feeling I’m liking a lot. And believe me, I’m pretty much aware that my current situation (married and with two children) is quite different compared to 7 years ago. Yet it doesn’t scare me well enough not to feel thrilled about this new stage in our life, a stage I’m already eager to deal with.

So it’s time to move on. I won’t ever forget the great time I had at Igalia, all the people I met here and all the good things that being part of such an special company brought to my life, but I also think now it’s time to look forward and focus on the future.

I have the most amazing family in the world and we’ll be together on this through thick and thin, so I’m already sure we’ll be fine. It’s just a matter of time we’ll get there, so what else can I ask for?

Just wish us good luck. That should do the rest :)

WebKitGTK+ 1.10 is almost here!

Published / by mario / 4 Comments on WebKitGTK+ 1.10 is almost here!

As you might already know, the new and shiny 3.6 release of the GNOME desktop is right around the corner, and so it’s the next release of WebKitGTK+, the port of the WebKit web rendering engine to the GTK+ platform.

And it turns out that such a release is going to be a very special one for us, members of the WebKit team at Igalia,  since it comes with some very interesting features, like those I already mentioned in the talk I gave during the past GUADEC, mainly:

  • Beta version of the WebKit2GTK+ API
  • Support for Accelerated Compositing
  • WebGL enabled by default
  • Support for HTML5 Fullscreen and WebAudio
  • Multimedia layer ported to GStreamer 0.11
  • Support for the Low-Level Interpreter in JavaScriptCore

From all those, I’m specially happy because we will be finally releasing the very first beta version of the new WebKit2GTK+ API, based in the multi-process architecture of WebKit2, as well as providing support for Accelerated Compositing and WebGL.

This new WebKit2GTK+ API, as you perhaps already know, will allow applications gain the split process model of WebKit2 out-of-the box, which is awesome. Xan already mentioned  some of the advantages of it becoming beta for GNOME 3.6 in his last post this week, being my favorite ones the “increased responsiveness and stability” (quoting Xan) that will come with it, as well as the fact that it will be not only powerful enough to port old applications and write new ones, but also simpler and easier to use (we are putting a lot of effort on this).

And honestly, I think we are doing pretty well in that regard, even though there’s still a lot of work to do before we can release an stable version of this new API (due for WebKitGTK+ 2.0,  to be released with GNOME 3.8), which will also mean the very first version of Epiphany that will be using WebKit2 by default.

With regard to Accelerated Compositing and WebGL, I’d just like to mention that having them supported in WebKitGTK+ from now on is great because it means you will be able to render visually stunning web content in your browser of choice (epiphany, huh?), as well as enjoy more subtle improvements such as smoother animations or increased responsivenes while browsing. You can visit this post by my mate Martin for more details on this topic.

Anyway, all these are very nice words and all that, but sometimes it’s not that easy to properly understand just with words what exactly those things will actually mean for users, so I decided to spend some time today polishing a bit the videos I used as demos in my talk during GUADEC, and link them from here, so everyone can easily watch them now.

Hope you enjoy watching them as much as I did making them:

WebKitGTK+: WebGL and Accelerated Compositing

WebKit2GTK+: The UI and the Web process

WebKit2GTK+: The Plugin process

GUADEC, WebKit and bikes

Published / by mario

I'm going to GUADECIt seems this year GUADEC is going to be pretty close to my place and so I will surely attend, but this time I won’t go by plane but by bike, which since some months ago has become my main vehicle for moving around the beautiful city where I live in: A Coruña.

Also, besides hanging around the venue and trying to help as much as possible as the local I am, I’ll be talking about WebKitGTK+ in the afternoon on Thursday 26th, so feel free to come round the room if you feel curious about the current status of the whole thing and the current plans for the short and medium term, which are mostly focused around WebKit2 and the roadmap we’re already following.

You probably already read some news related to this coming from my mates in the Igalia WebKit team, (like the improvements in Accelerated Compositing or the migration of our handsome browser Epiphany to using WebKit2), yet I will try to deliver an interesting talk to y’all. I just hope I’ll be able to do it (but please forgive me if I don’t).

So that’s it. As usual, just feel free to talk me if you see me around if you want. I’ll basically be around the venue most of the time during GUADEC, and will attend a11y and WebKitGTK+ BoFs on the 30th and 31st, so I’d say it will be pretty easy to find me.

WebKit Watcher 0.2 released

Published / by mario / 2 Comments on WebKit Watcher 0.2 released

Some time ago I wrote a (very!) small android application to scratch an itch I had: being able to easily check the status of WebKit buildbots right from my phone, which turned out to be quite useful in some scenarios.

And no, I’m not the kind of guy that does the “Land Patch / Goes Home” thing, but sometimes you see yourself in the situation of having to leave your workplace before than expected and after having committed certain kind of patches a while ago. And in such a situation WebKit Watcher has proved to be a helpful tool many times, at least to me.

So, what’s new in this 0.2 release? Not many bells and whistles, to be honest, I just scratched a couple of small itches more I felt today, while going back to working as gardener for the WebKitGTK+ port. Basically:

  • Replaced the main view showing only the core bots with a (static) list of the different platforms, so you know can  now check the results for all the bots of a specific platform. Selecting a platform will take you to the typical view showing the results for every build bot associated to it.
  • Added possibility of checking the results for all the bots in a single list view (‘All’ item in the main view), as previously only those “marked” as ‘core bots’ were shown in the application. Now you can check the results of all the 43 bots, in case you want to.
  • Removed unnecessary permission CHANGE_NETWORK_STATE, as I personally hate apps asking me for more permissions than those strictly needed. I’m still wondering why I added that in the first place…

And now, some screenshots that will make your eyes bleed because of the ‘design’ of this app:

  

I told you it was so beautiful!

By the way, you can grab it and install this app through several ways:

Back to FOSDEM

Published / by mario

So it seems I’m going to FOSDEM this year (yay!), together with a bunch of other Igalians who will be attending as well, coming from different places from across the globe (well, mainly from Europe this time).

I know some people will probably disagree with me on this, but for me FOSDEM is one of the greatest events of this kind, and so I’m quite happy to go there this time, specially after not being able to attend last year due to some unexpected (and unavoidable) personal matters.

Opposite to other occasions, this time I’ll be there not only as an attendant but also as an speaker, talking about WebKitGTK+, its status and the roadmap of the project towards WebKit2 (the split process model “flavour” of WebKit), together with my mate Philippe, on Sunday afternoon. Thus, for the first time ever, nobody will be able to accuse me of going there just because of the beer event, which wouldn’t be true anyway.

For the impatient ones, the talk will be mainly about reporting on the work done during the last months in “WebKitGTK+ land“, as well as on the stuff that is already planned for the upcoming releases. Good examples of those would be, for instance, the ongoing effort to add support for Accelerated Compositing, or just the new features related to WebKit2GTK+ such as, of course, the solution for enabling accessibility support there. Ah! And of course, we’ll try to run some demos there too… fingers crossed!

Besides, I’m of course looking forward to meeting some people I haven’t seen for a while now (haven’t attended to the latest Desktop Summit either, due to very good reasons too), so if you see me around and want to chat and/or meet for a while, just let me know. I must look shy, but it’s usually a matter of minutes (seconds?) for my shyness to go away…

So that’s it. Just a final line to say “thanks” to my company for fully sponsoring this thing.

See you in Brussels!

Accessibility support in WebKit2GTK+

Published / by mario / 1 Comment on Accessibility support in WebKit2GTK+

As Piñeiro already mentioned in some posts, last week a bunch of hackers attended the ATK/AT-SPI Hackfest 2012 here at the Igalia offices, in the lovely city of Coruña.

As the guy working on accessibility support for WebKitGTK+, I attended the hackfest to join some other great people representing different projects, such as Mozilla, Orca, AT-SPI, ATK, GTK+ and Qt. So, apart from helping with some “local” organizational details of the hackfest and taking some pictures, I spent some time hacking in WebKitGTK+‘s accessibility code and participating in some discussions.

And from that dedication I managed to achieve some interesting things too, being my favorite ones a big refactoring of the a11y code in WebCore (so it’s now better organized and hence more readable and easy to hack on) and pushing my patch for enabling accessibility support in WebKit2GTK+, after going through a meticulous process of review (see the related WK bug), which started with the patch I wrote and attached back when attending to the WebKitGTK+ hackfest, as I mentioned in my previous entry in this blog.

Yeah, I know that some weeks have already passed since then and so perhaps you’re thinking this could have been done faster… but I’ve spent some weeks on holidays in Barcelona in December (pictures here!) and so I wouldn’t have much time before January to devote to this task. However, the patch got integrated faster than what I would expect when I proposed the first version of it, so I’m quite satisfied and happy anyway just by being able to announce this at this moment. Hope you share my joy :-)

So, what does this mean from the point of view of accessibility in GNOME? Well, that’s an easy question to answer: from now on, every browser that uses WebKit2GTK+ will be as much accessible as those using the previous version of WebKitGTK+, and this is definitely a good thing. Of course, I’m certain there will be bugs in this specific part that will need fixing (as it always happens), but for the time being this achievement means “yet another thing less” preventing us from pushing for upgrading some applications to switch to WebKit2GTK+, such as devhelp (some ongoing work already done, as my mate Carlos announced yesterday), yelpliferea… and the mighty Epiphany browser, which is rocking more and more ech day that goes by.

Last, I’d like to share with you an screenshot showing this new stuff, but as I am a little bit tired of always using Minibrowser (that small browser we use for testing WebKit2), so I decided to try instead that new branch Carlos recently pushed for devhelp, so you could check that what I mentioned before is actually true.

So here you have it (along with a couple of additions done with Gimp):

As you can see, devhelp is running and Accerciser is showing the full hierarchy of accessible objects associated to the application, starting in the UI process (GTK+ world) and continuing in the Web process, where all the accessible objects from the WebKitGTK+ world are being exposed. As I explained in a previous post, the magic making possible the connection between the two process is done by means of the AtkSocket and the AtkPlug classes, also represented in the screenshot attached above.

So, that’s it.

WebKitGTK+ Hackfest: WK2, a11y and Ephiphany’s ad blocker extension

Published / by mario

Some posts have been already published about this during the last days, but just in case you missed them I will mention it here again: Last week, a bunch of hackers gathered together in the Igalia office in Coruña for the third edition of the WebKitGTK+ hackfest , and a lot of work has been done, as Juanjo has already summarized in his “WebKitGTK+ hackfest wrap up” post.

WebKitGTK+ 2011 Hackfest

So, as everything has been already said from a more general perspective, I’d like to write my very personal wrap up here, focused on the tasks that I’ve been working on, which can be summarized in three:

  • Enabling accessibility support in WebKit2GTK+.
  • Rewrite of the Ad Blocker extension for Epiphany.
  • Bug fixing in WebKitGTK+‘s accessibility related code.

Enabling accessibility support in WebKit2GTK+

This has been, by far, the task I devoted most of the time to during the hackfest, mainly focused on writing a ‘feature complete’ patch that could be applied upstream, and thus that could be reviewed in first place. But, what do I mean by “a ‘feature complete’ patch”? Well, perhaps you are already aware of the initial results already got in the WebKit2GTK+ a11y realm, but those results were obtained with a patch still in a very early state and, among other things, lacking a very important requirement for getting it accepted upstream: tests.

Fortunately, I can now proudly say that I managed to find a good way to write those tests (specially tricky due to the multiprocess architecture of WebKit2) and that there shouldn’t be any problem either with getting them work properly in the buildbots, which was something I was quite concerned about by the begining of the week, to be honest.

Besides the tests, the other obvious problem was that such a patch was not widely tested yet with the Orca screen reader (I use Accerciser for development purposes most of the time), and that would for sure unveil issues that would need fixing before being really able to propose a patch for reviewing, and so that was the other aspect where I put the spotlight during this week.

And regarding to this, I have to say that Joanmarie Diggs was working tirelessly by testing Orca with my WebKit2GTK+ a11y patch, reporting bugs, and helping me a lot to prioritize the tasks that would need to be done. From all those, I mainly worked this week in the following ones:

  • Emitting the AtkDocument’s signals (‘load-complete’, ‘load-stopped’ and ‘reload’), which was working only in WebKitGTK+ but not in WebKit2GTK+. See the bug report and the patch (still pending on review) for this issue in bug 73750. Also, I reported and worked for a while in another bug related to this, which is now already fixed upstream (see bug 73746). Yay!
  • Ensure that the accessibility hierarchy doesn’t break when (re)loading, which was causing that Orca stopped speaking unless it “manually” drilled down the full a11y hierarchy after the (re)load. I finally fixed that issue yesterday and integrated it in the patch for enabling a11y support in WebKit2GTK+, now already attached and pending on review along with bug 72589.

So, the conclusion of this part would be that we have now a patch in WebKit’s bugzilla (see bug 72589) that, once it’s approved, would enable accessibility in WebKit2GTK+ once and for all. Of course, this will probably take some time before it gets accepted upstream, but it’s yet another nice milestone in my opinion, and I personally hope it would happen on time for GNOME 3.4. Time will tell, though.

Rewrite of the Ad Blocker extension for Epiphany

This was another thing I’ve been randomly working on since some time ago (whenever “spare” time permitted), and that I was able to advance quite a lot right after coming back from the parental leave I enjoyed on September (did I say my second child was born on August the 30th?). However, the patch was not finished by any means, and some issues kindly pointed by Xan in bugzilla needed fixing before being able to say aloud something like “hey, the new ad blocker is now in town!”.

Thus, we thought it would be good to devote some time during the hackfest to try to close this task too, so we did: Xan reviewed the new version of the patch (addressing the issues he previously pointed out), I made some last changes based on that new feedback from him and we finally pushed it to the repository, replacing the old ad blocker extension with this new one, which is based in Midori‘s ad blocker and so is compatible with Adblock Plus filters, which work very well IMHO.

So, this basically means that the new ad blocker extension will be present from Epiphany 3.4 on. Check out the related bug in GNOME‘s bugzilla: bug 660154

Bug fixing in WebKitGTK+’s accessibility related code

Besides working in the WebKit2GTK+ a11y realm and on finishing the new ad blocker extension, I’ve also spent some time (although not as much as I would have wanted) fixing regressions in WebKitGTK+‘s a11y code as reported by Joanie (basically bug 72804 and bug 72830).

Compared to the other two points, this has been of course a pretty small contribution, but worth doing anyway since they were very important for Orca to work properly with WebKitGTK+ based browsers (special mention to bug 72830 here).

Conclusion

From the work-related point of view, I’d say this hackfest has been highly productive in general, as we achieved many goals which, as Juanjo pointed out in his wrap up post, “were not mainly about fixing critical and blocker bugs and implementing basic missing features, but about more ambitious and challenging” ones. As for me, I’m pretty happy with the results I got, specially with the WK2 a11y patch, which has now a much better shape, and so I hope we can integrate it soon upstream.

And from a more personal point of view, I’d like to say I had a great time (again!) this year in the hackfest, and not only because of the achiements got, but also because I had quite a lot of fun as well, because I met new people and because I felt, more than ever, part of a community and a project which I love.

To finish, I’d just like to mention that I’ve been taking some pictures during the hackfest, which you can check out in this photo set in flickr (pictures uploaded with Frogr, of course!). Nayan has also taken some pictures as well, check them out here.

WebKitGTK+ 2011 Hackfest (The End)

Of course, thanks a lot to the sponsors that made this possible: Collabora, Motorola, Igalia and the always awesome GNOME Foundation. I hope we’ll be able to repeat it next year, since this hackfest it’s only getting more and more awesome every time it happens.

Orca and WebKit2GTK+: initial results

Published / by mario

Last May, I wrote about some initial tests I did back then with AtkSocket and AtkPlug, just to learn a bit about that API that allows connecting accessibility trees in different processes, thanks to the magic of the ATK bridge. I did that in order to prepare for the work that would probably be needed when adding accessibility support in WebKit2GTK+, so browsers using the new version of this web engine could be at least as much accessible as those using the single-process WebKitGTK+ library. Looking back, I think that the effort has definitely payed off…

However, because of one reason or another (and not necessarily work-related), I was not able to devote much time to keep working on this until some weeks ago, but fortunately I’m now again working on this as my primary task in Igalia, as part of our WebKit team, so I expect to have some nice results soon, hopefully also in the form of integrated patches upstream.

And talking about results, I can’t avoid sharing the following at this very same moment, which is actually the trigger that made me write this post: today I was able to make Orca read, for the very first time, web content rendered through WebKit2GTK’s MiniBrowser, which has been not an easy task since the multiprocess architecture of WebKit2 made it a little bit challenging, to say the least.

Of  course there’s still much to do in this regard, so do not think of the current status of the task as it was nearly finished or anything… but still I thought it was a nice milestone to share with the world, and what a better way to do it than using a video for that. After all, Orca‘s main job is about speaking, right?. So here it is:

Orca and WebKit2GTK+: initial results (in Vimeo)

By the way, I’d like to make the most of this post by saying I’m really proud and happy to have Joanmarie Diggs aboard in Igalia for a few weeks now, who contributed a lot to making possible that I was writing this post today. Thanks , Joanie!

WebKit Contributors Meeting, sockets & plugs

Published / by mario / 1 Comment on WebKit Contributors Meeting, sockets & plugs

Last week some of the members of the Igalia WebKit team,  attended to the second edition of the WebKit Contributors Meeting in Cupertino, California, in order to gather round with other WebKit contributors to discuss and work around our favorite web engine, away from IRC and with a more personal and “human” touch.

WebKit Contributors Meeting '11 - group photo

As for me, it was the first time I attended this unconference and I have to say it was a great experience overall, even if accessibility (the field I usually work on through the GTK port of WebKit) was not precisely a hot topic there. But in the other hand, I managed to put some faces to people I just knew from IRC, attended to several interesting discussions and sessions, did some actual work ™ and met Chris Fleizach, the guy from Apple involved in accessibility for the Mac port, who attended the meeting on Tuesday morning and discussed with me some interesting topics, mainly about the implementation of the accessibility support in the Mac port of WebKit2.

For those of you that are not up to date with what WebKit2 means and what’s the current state of the whole thing, I’d recommend you to take a look to the WebKit2 wiki, although I can already advance you that one of the main features (if not the main one) of WebKit2 is the new multi-process architecture, which will go bundled right along with the engine, instead of doing the split in the final application, like Google Chrome does now with WebKit1 (see the wiki for more details, and some nice diagrams too, like the following one).

WebKit2 multi-process architecture

The problem however, from the accessibility point of view, is how to expose such a new architecture to Assistive Technologies (ATs) while, at the same time, having those ATs seeing just one process (the UI process), regardless of the different processes that would be running on each of the tabs (the Web proceses). In other words, how to “hide” to the ATs that they are extracting accessibility related information from a multi-process based browser, so they still keep the illusion of having only one application exposing accessibility objects, as it used to be so far.

Talking to Chris about how they implemented this in the Mac port, he told me they basically needed to make up a way to transparently connect the UI process and the Web Process, so navigation between the root accessibility object in the Web Process and the “leaf” accessibility object in the UI process were done in a seamless way, through a mechanism that would basically allow bidirectional communication in the same way it used to be when there was just one process running. This makes a lot of sense, if you ask me, since you “just” (saying it as if it were not a complex task, even though it actually is) add this mechanism to WebKit2 accessibility code and you’ll automagically get your ATs working as they used to work, without any other changes needed from their side.

However, when it comes to ATK/AT-SPI, which is what we currently use in GNOME to expose accessible objects from applications to ATs, it looks like such a mechanism (or something pretty similar) is already available by means of the AtkSocket and the AtkPlug classes, both subclasses of AtkObject, which basically act as a bridge that allows to connect two AtkObject‘s so the children of one of those (the Plug) are exposed as children of the other one (the Socket), no matter they’re in the same process or in different ones. And this, unless I’m missing something, is exactly what we’d need in WebKit2, probably along with some other things and tweaks that I just can’t think of at this moment. But at least is definitely a very good start point, IMHO.

But… how to communicate those sockets and plugs if they are in different processes? You might be wondering… Well, if you are using the D-Bus implementation of AT-SPI, also known as AT-SPI2, the needed bits for that (the implementation for the atk_socket_embed() and atk_plug_get_id() functions) are already implemented by the ATK bridge (at-spi2-atk), so the only thing you’ll need to do is to provide the remaining implementation of the AtkSocket and AtkPlug classes, register those new AtkObject‘s as the right accessible objects for your widgets (or whatever your “normal” objects are) and to use the ID that at-spi2-atk provides for the AtkPlug object to connect from the AtkSocket object… and you’re done.

However, I have to say that the documentation I’ve found so far about AtkSocket and AtkPlug is not precisely very detailed, so I basically ended up looking directly at the code and trying to write myself a small example to better understand things. And at this point, I asked in the #a11y channel in GIMPNet and it was Mike Gorse who kindly handed me out a nice tarball with an example they had written in C#, which was exactly what I was looking for. Yay! Thanks, Mike!

However, I’d be more interested in a plain C, GObject based, implementation of that example which would serve me both to better understand how it works and to use it as the base for further tests in WebKitGTK, so I went ahead and wrote it, and this is how the results look now, as seen through Accerciser‘s eyes:

AtkSocket / AtkPlug example in action

As you can see, there are two processes running, ta-socket and ta-plug, and in ta-socket we have an AtkObject named “The Socket” which is exposing, as his only child, the whole subtree present in the other process ta-plug, starting in another AtkObject named “The Plug”… which is exactly, although of course at a much smaller dimension, what I think we would like to see happening in the accessibility tree of any WebKitGTK based application in the future, once that WebKit2 is mature enough to replace WebKit1.

Obviously, this shouldn’t be taken as a “we’re done with WebKitGTK/WebKit2 when it comes to a11y” comment or the like. Actually this is just the beginning of the whole thing… But I think, or at least I would like to think, that is at least a good start point :-).

And before you shoot… “yes”, I’m already planning to help improve the ATK documentation in this regard with the knowledge I acquired while working on this examples, even perhaps next week during the ATK/AT-SPI hackfest (it’s actually one of the proposed tasks) I’ll be attending here in Coruña, at the Igalia offices.

By the way, feel free to grab the source for this example from its git respository at gitorious:

git clone http://git.gitorious.org/atksocket-atkplug-example/mainline.git