Category Archives: Planet Igalia

Posts to be imported from planet.igalia.com

End of the year Update: 2019 edition

Published / by mario / Leave a Comment

It’s the end of December and it seems that yet another year has gone by, so I figured that I’d write an EOY update to summarize my main work at Igalia as part of our Chromium team, as my humble attempt to make up for the lack of posts in this blog during this year.

I did quit a few things this year, but for the purpose of this blog post I’ll focus on what I consider the most relevant ones: work on the Servicification and the Blink Onion Soup projects, the migration to the new Mojo APIs and the BrowserInterfaceBroker, as well as a summary of the conferences I attended, both as a regular attendee and a speaker.

But enough of an introduction, let’s dive now into the gory details…

Servicification: migration to the Identity service

As explained in my previous post from January, I’ve started this year working on the Chromium Servicification (s13n) Project. More specifically, I joined my team mates in helping with the migration to the Identity service by updating consumers of several classes from the sign-in component to ensure they now use the new IdentityManager API instead of directly accessing those other lower level APIs.

This was important because at some point the Identity Service will run in a separate process, and a precondition for that to happen is that all access to sign-in related functionality would have to go through the IdentityManager, so that other process can communicate with it directly via Mojo interfaces exposed by the Identity service.

I’ve already talked long enough in my previous post, so please take a look in there if you want to know more details on what that work was exactly about.

The Blink Onion Soup project

Interestingly enough, a bit after finishing up working on the Identity service, our team dived deep into helping with another Chromium project that shared at least one of the goals of the s13n project: to improve the health of Chromium’s massive codebase. The project is code-named Blink Onion Soup and its main goal is, as described in the original design document from 2015, to “simplify the codebase, empower developers to implement features that run faster, and remove hurdles for developers interfacing with the rest of the Chromium”. There’s also a nice slide deck from 2016’s BlinkOn 6 that explains the idea in a more visual way, if you’re interested.


“Layers”, by Robert Couse-Baker (CC BY 2.0)

In a nutshell, the main idea is to simplify the codebase by removing/reducing the several layers of located between Chromium and Blink that were necessary back in the day, before Blink was forked out of WebKit, to support different embedders with their particular needs (e.g. Epiphany, Chromium, Safari…). Those layers made sense back then but these days Blink’s only embedder is Chromium’s content module, which is the module that Chrome and other Chromium-based browsers embed to leverage Chromium’s implementation of the Web Platform, and also where the multi-process and sandboxing architecture is implemented.

And in order to implement the multi-process model, the content module is split in two main parts running in separate processes, which communicate among each other over IPC mechanisms: //content/browser, which represents the “browser process” that you embed in your application via the Content API, and //content/renderer, which represents the “renderer process” that internally runs the web engine’s logic, that is, Blink.

With this in mind, the initial version of the Blink Onion Soup project (aka “Onion Soup 1.0”) project was born about 4 years ago and the folks spearheading this proposal started working on a 3-way plan to implement their vision, which can be summarized as follows:

  1. Migrate usage of Chromium’s legacy IPC to the new IPC mechanism called Mojo.
  2. Move as much functionality as possible from //content/renderer down into Blink itself.
  3. Slim down Blink’s public APIs by removing classes/enums unused outside of Blink.

Three clear steps, but definitely not easy ones as you can imagine. First of all, if we were to remove levels of indirection between //content/renderer and Blink as well as to slim down Blink’s public APIs as much as possible, a precondition for that would be to allow direct communication between the browser process and Blink itself, right?

In other words, if you need your browser process to communicate with Blink for some specific purpose (e.g. reacting in a visual way to a Push Notification), it would certainly be sub-optimal to have something like this:

…and yet that is what would happen if we kept using Chromium’s legacy IPC which, unlike Mojo, doesn’t allow us to communicate with Blink directly from //content/browser, meaning that we’d need to go first through //content/renderer and then navigate through different layers to move between there and Blink itself.

In contrast, using Mojo would allow us to have Blink implement those remote services internally and then publicly declare the relevant Mojo interfaces so that other processes can interact with them without going through extra layers. Thus, doing that kind of migration would ultimately allow us to end up with something like this:

…which looks nicer indeed, since now it is possible to communicate directly with Blink, where the remote service would be implemented (either in its core or in a module). Besides, it would no longer be necessary to consume Blink’s public API from //content/renderer, nor the other way around, enabling us to remove some code.

However, we can’t simply ignore some stuff that lives in //content/renderer implementing part of the original logic so, before we can get to the lovely simplification shown above, we would likely need to move some logic from //content/renderer right into Blink, which is what the second bullet point of the list above is about. Unfortunately, this is not always possible but, whenever it is an option, the job here would be to figure out what of that logic in //content/renderer is really needed and then figure out how to move it into Blink, likely removing some code along the way.

This particular step is what we commonly call “Onion Soup’ing //content/renderer/<feature>(not entirely sure “Onion Soup” is a verb in English, though…) and this is for instance how things looked before (left) and after (right) Onion Souping a feature I worked on myself: Chromium’s implementation of the Push API:


Onion Soup’ing //content/renderer/push_messaging

Note how the whole design got quite simplified moving from the left to the right side? Well, that’s because some abstract classes declared in Blink’s public API and implemented in //content/renderer (e.g. WebPushProvider, WebPushMessagingClient) are no longer needed now that those implementations got moved into Blink (i.e. PushProvider and PushMessagingClient), meaning that we can now finally remove them.

Of course, there were also cases where we found some public APIs in Blink that were not used anywhere, as well as cases where they were only being used inside of Blink itself, perhaps because nobody noticed when that happened at some point in the past due to some other refactoring. In those cases the task was easier, as we would just remove them from the public API, if completely unused, or move them into Blink if still needed there, so that they are no longer exposed to a content module that no longer cares about that.

Now, trying to provide a high-level overview of what our team “Onion Soup’ed” this year, I think I can say with confidence that we migrated (or helped migrate) more than 10 different modules like the one I mentioned above, such as android/, appcache/, media/stream/, media/webrtc, push_messaging/ and webdatabase/, among others. You can see the full list with all the modules migrated during the lifetime of this project in the spreadsheet tracking the Onion Soup efforts.

In my particular case, I “Onion Soup’ed” the PushMessagingWebDatabase and SurroundingText features, which was a fairly complete exercise as it involved working on all the 3 bullet points: migrating to Mojo, moving logic from //content/renderer to Blink and removing unused classes from Blink’s public API.

And as for slimming down Blink’s public API, I can tell that we helped get to a point where more than 125 classes/enums were removed from that Blink’s public APIs, simplifying and reducing the Chromium code- base along the way, as you can check in this other spreadsheet that tracked that particular piece of work.

But we’re not done yet! While overall progress for the Onion Soup 1.0 project is around 90% right now, there are still a few more modules that require “Onion Soup’ing”, among which we’ll be tackling media/ (already WIP) and accessibility/ (starting in 2020), so there’s quite some more work to be done on that regard.

Also, there is a newer design document for the so-called Onion Soup 2.0 project that contains some tasks that we have been already working on for a while, such as “Finish Onion Soup 1.0”, “Slim down Blink public APIs”, “Switch Mojo to new syntax” and “Convert legacy IPC in //content to Mojo”, so definitely not done yet. Good news here, though: some of those tasks are already quite advanced already, and in the particular case of the migration to the new Mojo syntax it’s nearly done by now, which is precisely what I’m talking about next…

Migration to the new Mojo APIs and the BrowserInterfaceBroker

Along with working on “Onion Soup’ing” some features, a big chunk of my time this year went also into this other task from the Onion Soup 2.0 project, where I was lucky enough again not to be alone, but accompanied by several of my team mates from Igalia‘s Chromium team.

This was a massive task where we worked hard to migrate all of Chromium’s codebase to the new Mojo APIs that were introduced a few months back, with the idea of getting Blink updated first and then having everything else migrated by the end of the year.


Progress of migrations to the new Mojo syntax: June 1st – Dec 23rd, 2019

But first things first: you might be wondering what was wrong with the “old” Mojo APIs since, after all, Mojo is the new thing we were migrating to from Chromium’s legacy API, right?

Well, as it turns out, the previous APIs had a few problems that were causing some confusion due to not providing the most intuitive type names (e.g. what is an InterfacePtrInfo anyway?), as well as being quite error-prone since the old types were not as strict as the new ones enforcing certain conditions that should not happen (e.g. trying to bind an already-bound endpoint shouldn’t be allowed). In the Mojo Bindings Conversion Cheatsheet you can find an exhaustive list of cases that needed to be considered, in case you want to know more details about these type of migrations.

Now, as a consequence of this additional complexity, the task wouldn’t be as simple as a “search & replace” operation because, while moving from old to new code, it would often be necessary to fix situations where the old code was working fine just because it was relying on some constraints not being checked. And if you top that up with the fact that there were, literally, thousands of lines in the Chromium codebase using the old types, then you’ll see why this was a massive task to take on.

Fortunately, after a few months of hard work done by our Chromium team, we can proudly say that we have nearly finished this task, which involved more than 1100 patches landed upstream after combining the patches that migrated the types inside Blink (see bug 978694) with those that tackled the rest of the Chromium repository (see bug 955171).

And by “nearly finished” I mean an overall progress of 99.21% according to the Migration to new mojo types spreadsheet where we track this effort, where Blink and //content have been fully migrated, and all the other directories, aggregated together, are at 98.64%, not bad!

On this regard, I’ve been also sending a bi-weekly status report mail to the chromium-mojo and platform-architecture-dev mailing lists for a while (see the latest report here), so make sure to subscribe there if you’re interested, even though those reports might not last much longer!

Now, back with our feet on the ground, the main roadblock at the moment preventing us from reaching 100% is //components/arc, whose migration needs to be agreed with the folks maintaining a copy of Chromium’s ARC mojo files for Android and ChromeOS. This is currently under discussion (see chromium-mojo ML and bug 1035484) and so I’m confident it will be something we’ll hopefully be able to achieve early next year.

Finally, and still related to this Mojo migrations, my colleague Shin and I took a “little detour” while working on this migration and focused for a while in the more specific task of migrating uses of Chromium’s InterfaceProvider to the new BrowserInterfaceBroker class. And while this was not a task as massive as the other migration, it was also very important because, besides fixing some problems inherent to the old InterfaceProvider API, it also blocked the migration to the new mojo types as InterfaceProvider did usually rely on the old types!


Architecture of the BrowserInterfaceBroker

Good news here as well, though: after having the two of us working on this task for a few weeks, we can proudly say that, today, we have finished all the 132 migrations that were needed and are now in the process of doing some after-the-job cleanup operations that will remove even more code from the repository! \o/

Attendance to conferences

This year was particularly busy for me in terms of conferences, as I did travel to a few events both as an attendee and a speaker. So, here’s a summary about that as well:

As usual, I started the year attending one of my favourite conferences of the year by going to FOSDEM 2019 in Brussels. And even though I didn’t have any talk to present in there, I did enjoy my visit like every year I go there. Being able to meet so many people and being able to attend such an impressive amount of interesting talks over the weekend while having some beers and chocolate is always great!

Next stop was Toronto, Canada, where I attended BlinkOn 10 on April 9th & 10th. I was honoured to have a chance to present a summary of the contributions that Igalia made to the Chromium Open Source project in the 12 months before the event, which was a rewarding experience but also quite an intense one, because it was a lightning talk and I had to go through all the ~10 slides in a bit under 3 minutes! Slides are here and there is also a video of the talk, in case you want to check how crazy that was.

Took a bit of a rest from conferences over the summer and then attended, also as usual, the Web Engines Hackfest that we at Igalia have been organising every single year since 2009. Didn’t have a presentation this time, but still it was a blast to attend it once again as an Igalian and celebrate the hackfest’s 10th anniversary sharing knowledge and experiences with the people who attended this year’s edition.

Finally, I attended two conferences in the Bay Area by mid November: first one was the Chrome Dev Summit 2019 in San Francisco on Nov 11-12, and the second one was BlinkOn 11 in Sunnyvale on Nov 14-15. It was my first time at the Chrome Dev Summit and I have to say I was fairly impressed by the event, how it was organised and the quality of the talks in there. It was also great for me, as a browsers developer, to see first hand what are the things web developers are more & less excited about, what’s coming next… and to get to meet people I would have never had a chance to meet in other events.

As for BlinkOn 11, I presented a 30 min talk about our work on the Onion Soup project, the Mojo migrations and improving Chromium’s code health in general, along with my colleague Antonio Gomes. It was basically a “extended” version of this post where we went not only through the tasks I was personally involved with, but also talked about other tasks that other members of our team worked on during this year, which include way many other things! Feel free to check out the slides here, as well as the video of the talk.

Wrapping Up

As you might have guessed, 2019 has been a pretty exciting and busy year for me work-wise, but the most interesting bit in my opinion is that what I mentioned here was just the tip of the iceberg… many other things happened in the personal side of things, starting with the fact that this was the year that we consolidated our return to Spain after 6 years living abroad, for instance.

Also, and getting back to work-related stuff here again, this year I also became accepted back at Igalia‘s Assembly after having re-joined this amazing company back in September 2018 after a 6-year “gap” living and working in the UK which, besides being something I was very excited and happy about, also brought some more responsibilities onto my plate, as it’s natural.

Last, I can’t finish this post without being explicitly grateful for all the people I got to interact with during this year, both at work and outside, which made my life easier and nicer at so many different levels. To all of you,  cheers!

And to everyone else reading this… happy holidays and happy new year in advance!

Working on the Chromium Servicification Project

Published / by mario

Igalia & ChromiumIt’s been a few months already since I (re)joined Igalia as part of its Chromium team and I couldn’t be happier about it: right since the very first day, I felt perfectly integrated as part of the team that I’d be part of and quickly started making my way through the -fully upstream- project that would keep me busy during the following months: the Chromium Servicification Project.

But what is this “Chromium servicification project“? Well, according to the Wiktionary the word “servicification” means, applied to computing, “the migration from monolithic legacy applications to service-based components and solutions”, which is exactly what this project is about: as described in the Chromium servicification project’s website, the whole purpose behind this idea is “to migrate the code base to a more modular, service-oriented architecture”, in order to “produce reusable and decoupled components while also reducing duplication”.

Doing so would not only make Chromium a more manageable project from a source code-related point of view and create better and more stable interfaces to embed chromium from different projects, but should also enable teams to experiment with new features by combining these services in different ways, as well as to ship different products based in Chromium without having to bundle the whole world just to provide a particular set of features. 

For instance, as Camille Lamy put it in the talk delivered (slides here) during the latest Web Engines Hackfest,  “it might be interesting long term that the user only downloads the bits of the app they need so, for instance, if you have a very low-end phone, support for VR is probably not very useful for you”. This is of course not the current status of things yet (right now everything is bundled into a big executable), but it’s still a good way to visualise where this idea of moving to a services-oriented architecture should take us in the long run.

Chromium Servicification Layers

With this in mind, the idea behind this project would be to work on the migration of the different parts of Chromium depending on those components that are being converted into services, which would be part of a “foundation” base layer providing the core services that any application, framework or runtime build on top of chromium would need.

As you can imagine, the whole idea of refactoring such an enormous code base like Chromium’s is daunting and a lot of work, especially considering that currently ongoing efforts can’t simply be stopped just to perform this migration, and that is where our focus is currently aimed at: we integrate with different teams from the Chromium project working on the migration of those components into services, and we make sure that the clients of their old APIs move away from them and use the new services’ APIs instead, while keeping everything running normally in the meantime.

At the beginning, we started working on the migration to the Network Service (which allows to run Chromium’s network stack even without a browser) and managed to get it shipped in Chromium Beta by early October already, which was a pretty big deal as far as I understand. In my particular case, that stage was a very short ride since such migration was nearly done by the time I joined Igalia, but still something worth mentioning due to the impact it had in the project, for extra context.

After that, our team started working on the migration of the Identity service, where the main idea is to encapsulate the functionality of accessing the user’s identities right through this service, so that one day this logic can be run outside of the browser process. One interesting bit about this migration is that this particular functionality (largely implemented inside the sign-in component) has historically been located quite high up in the stack, and yet it’s now being pushed all the way down into that “foundation” base layer, as a core service. That’s probably one of the factors contributing to making this migration quite complicated, but everyone involved is being very dedicated and has been very helpful so far, so I’m confident we’ll get there in a reasonable time frame.

If you’re curious enough, though, you can check this status report for the Identity service, where you can see the evolution of this particular migration, along with the impact our team had since we started working on this part, back on early October. There are more reports and more information in the mailing list for the Identity service, so feel free to check it out and/or subscribe there if you like.

One clarification is needed, tough: for now, the scope of this migrations is focused on using the public C++ APIs that such services expose (see //services/<service_name>/public/cpp), but in the long run the idea is that those services will also provide Mojo interfaces. That will enable using their functionality regardless of whether you’re running those services as part of the browser’s process, or inside their own & separate processes, which will then allow the flexibility that chromium will need to run smoothly and safely in different kind of environments, from the least constrained ones to others with a less favourable set of resources at their disposal.

And this is it for now, I think. I was really looking forward to writing a status update about what I’ve been up to in the past months and here it is, even though it’s not the shortest of all reports.

FOSDEM 2019

One last thing, though: as usual, I’m going to FOSDEM this year as well, along with a bunch of colleagues & friends from Igalia, so please feel free to drop me/us a line if you want to chat and/or hangout, either to talk about work-related matters or anything else really.

And, of course, I’d be also more than happy to talk about any of the open job positions at Igalia, should you consider applying. There are quite a few of them available at the moment for all kind of things (most of them available for remote work): from more technical roles such as graphicscompilersmultimedia, JavaScript engines, browsers (WebKitChromium, Web Platform) or systems administration (this one not available for remotes, though), to other less “hands-on” types of roles like developer advocatesales engineer or project manager, so it’s possible there’s something interesting for you if you’re considering to join such an special company like this one.

See you in FOSDEM!

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:

Frogr 0.7 released

Published / by mario

As you might already know Flickr has added support for OAuth a while ago, which is meant to be the obvious replacement to the old Flickr auth API that has been available since a long long time ago, which has been used by many applications our there, like frogr. But the important point here for apps using the old auth method is that it won’t be longer available after July 31st, which means they should get updated if they want to keep working as so far.

Frogr 0.7

So, this is the main point of this release: to update the internal implementation of the Flickr REST API in frogr (which, ideally, will be released independently as a library at some point) to use OAuth instead of the old authentication API.

Additionally, in order to make things easier for users of older versions, the application will take care of exchanging the authentication token from the old system to the new ones used by the OAuth API. If you want to know more details about this, check the related API. For the rest of you, you shouldn’t notice anything the first time you run this new release.

Still, some other things were included in this new release that are worth mentioning:

  • Ability to import tags already present in pictures  (e.g. as set by f-spot or shotwell).
  • Allow users deciding, right from frogr and on a picture-by-picture basis, whether to set the geolocation information for pictures when uploading them to Flickr.
  • New tags are added to the auto-completion without having to upload anything first.
  • Allow using a dark version of your theme if available (e.g. Adwaita).
  • Some redesign of the menu bar, thinking of a future migration to GMenu.
  • Added menu accelerators for the most common operations.
  • As usual, bugfixes, cleanups… that kind of stuff.

Also, you can check the announcement mail or the NEWS file if you want for more detail about this new release, as well as the website of the project for additional information, such as knowing about ways of collaborating or how to get frogr installed on your system.

I think that’s it. Enjoy!

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!

Frogr 0.6.1 (bugfixing) release

Published / by mario / 3 Comments on Frogr 0.6.1 (bugfixing) release

Shit happens in many ways, and sometimes that means you release an application with some bugs you just can’t stand and need to roll out a bugfixing release as soon as possible. Does this sound familiar to you? :)

So that’s why this new release of frogr, just one week after the 0.6 version had been published, has arrived, taking care exclusively of fixing the following problems, as stated in the NEWS file:

  • Fix memory leaks, the most important one happening in the editing details dialog.
  • Problems using combo boxes with versions of GTK prior to 2.24.
  • Fixed problems authorizing frogr on the MacOSX version.

From those above, patches for some them were already included in the debian packages from frogr’s Ubuntu PPA and in the package for the Mac, but the most important ones -the leaks- were not, so that’s why I decided to roll this new version out.

So that’s all, if you were already an user of frogr, go and grab it through the usual ways.

Frogr 0.6 released

Published / by mario / 8 Comments on Frogr 0.6 released

After some changes here and there frogr 0.6 is finally out.

Frogr 0.6 running in GNOME 3

Besides the usual bugfixing work, the main new features on this release are:

  • Integration with the GNOME general proxy settings (optional).
  • Open pictures in the default image viewer  from the details dialog and the main view.
  • Allow users to specify the license to be set for the pictures.
  • A new User Manual, under “Help > Contents”.
  • Some UI improvements.

As usual, you can get frogr through different ways: you can grab the source code from its git repository or via the xz and bzip2 tarballs, specific packages for Fedora or for Ubuntu (ranging from Karmic to Oneiric) and even a version for MacOSX, if you dare to use it.

By the way, at the moment frogr is already being packaged in some distros (see this) and others might follow, so perhaps it could be that you already were able to install it by just using your favorite package manager with the standard repos. Otherwise, it might be just a matter of time, I guess…

For more information about the project and also how to contribute, check out its web site.

Last, but not least, I’d like to make an special mention here to the awesome Quinn Dombrowski, who very well could be the “most passionate frogr user I’ve ever known” and who was kind enough to design, handcraft and send -from Chicago to Spain- a stuffed frogr mascot plus a beautiful vest for my son (which design comes also with its own incredible story), as a sign of gratitude for writing this tiny app. I’m still shocked about it, see what I’m talking about:

Frogr mascot Onfim vest

If you want to see more pictures you can check my set in flickr, although I warn you these two ones taken by the artist are way better than mine :-)

Seriously Quinn… and yet once again: Thank you!

Frogr 0.5 released

Published / by mario / 6 Comments on Frogr 0.5 released

Now announcing that the new release of frogr is finally out.

This time, I’m afraid you won’t find huge changes in the application, but a bunch of small improvements instead, in the way of subtle -yet handy- new features, bug fixes and new and uptaded translations mainly. Still, I can mention some of the new small features that I specially like, since I use it a lot:

  • Uploading pictures stored in remote machines via well-known protocols like smb, ssh, ftp… well anything supported by GVFS, basically.
  • Sort pictures in the interface by title and date taken (and keep the pictures sorted as you add more pictures!).
  • Allow disabling tags autocompletion (seems to slow frogr down when you have thousands of tags).
  • Tooltips with basic info about the pictures in the icon view (title, size, date taken).
  • Show the total amount of data to be uploaded in the status bar.
  • Allow filling the details for pictures right from the photoset details, when creating a new one.
  • Correct picture orientation in the icon view, if needed (rotation).
  • Support both for Gtk+2 and Gtk+3 (now this is the default toolkit for building).
  • Support for generating MacOSX packages, thanks to the GTK-OSX project.
  • As usual, several other bug fixes, improvements and nitpicky stuff.

As usual, you can get it through different ways:

[Update 31/05/2011]: If you have already installed frogr 0.5 for Ubuntu from my PPA or from the pre-compiled packages, please do upgrade to the latest version of the Ubuntu packages as soon as possible, as available in my PPA. If you already have the PPA configured in your system, you can upgrade just frogr by simply doing this:

sudo apt-get update && sudo install frogr

There was a problem with the generation of the previous version of the packages for Ubuntu (files being installed under /tmp/frogr, instead of /usr/share) and all of them are broken and need to be updated. Sorry for the hassle.

If you want to contribute, remember you can do it by proposing ideas, translatingcodingdiscussing or filing and/or fixing bugs.

Also if you want to see frogr packaged for your favourite distro and can help with that (maybe you’re a packager or know better than me the required steps for that), that would be awesome. At the moment only Debian has packaged it so far that I know of (thanks Berto!), but I would love to see it also in other distros (specially in Fedora, which is what I currently use) so more people can use it without having to use either the Frogr PPA or the homegrown packages I usually prepare with each release.

For more information, just check out its web site. Here you have a screenshot of how frogr 0.5 looks in the awesome GNOME 3 in my Fedora box:

Frogr 0.5 running in GNOME 3

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

Visita a las “Xornadas Libres” del GPUL

Published / by mario / 2 Comments on Visita a las “Xornadas Libres” del GPUL

Gracias a la gente del GPUL, que me hicieron un hueco en la apretada (e interesante!) agenda de las “Xornadas Libres” de este año, hoy por la tarde he dado una charla en la Facultad de Informática de A Coruña acerca de git, uno de los sistemas de control de versiones más populares y más usados hoy en día.

Personalmente, tengo que reconocer que me cuesta ocultar mi pasión por esta herramienta, la cual tengo la suerte de poder disfrutar usando a diario, pero  espero que esa pasión no haya empañado la charla y que los asistentes, que aguantaron estoicamente el chaparrón de información hiper-concentrada que solté durante poco más de una hora, hayan extraído algo útil y positivo de la misma :-)

La charla fue básicamente una versión “evolucionada y extendida” de la charla que dí el pasado mes de Julio en la GUADEC-ES 2010, pero esta vez con un énfasis especial en explicar en más detalle algunas partes, así como de explicar/mencionar algunas cosas nuevas, lo cual hizo todavía más complicado que pudiese acabar en tiempo, pero bueno… al menos espero no haberme pasado demasiado.

Por último, para los que no hayan asistido, así como para los que hayan asistido pero no se hayan enterado de nada por mi forma un tanto apurada de dar la charla, aquí están las slides de la misma en formato PDF (en castellano).

Frogr 0.4 is out!

Published / by mario / 1 Comment on Frogr 0.4 is out!

As I said some days ago, in theory I should be releasing Frogr 0.4 this weekend while at FOSDEM, after a 2-week period of feature and string freeze to work on stabilization and bugfixing tasks only. Well, bad news (mainly for myself) is that I did not make it to FOSDEM at the end, due to unavoidable personal matters, but good news is that I’m finally making the release anyway today :-)

So Frogr 0.4 is now out and kicking since a couple of hours ago, featuring the following list of changes, as summarized today in the announcement mail:

  • Fixed capitalization problems (Philip Withnall).
  • Use Unicode ellipsis instead of three dots (Philip Withnall).
  • Allow compiling with gtk 3.0 by passing –with-gtk=3.0.
  • Raised minimum version required of GTK+ from 2.12 up to 2.14.
  • Removed dependency from libgnome.
  • Added new man page (Alberto Garcia).
  • Fixed slow startup. No longer wait for albums to be loaded.
  • New settings dialog to pre-set some values.
  • Support for HTTP proxies, through libsoup’s API.
  • Renamed “Albums” to “Sets”.
  • Support for creating new sets right from frogr.
  • Allow adding pictures to group pools, not just to user albums.
  • Allow changing sorting order in ‘add to album/group’ dialogs.
  • Support for seamlessly handling multiple accounts.
  • Auto-completion in ‘tags’ entries.
  • Allow setting ‘content type’ and ‘safety level’.
  • Allow setting pictures to ‘show up on global search results’.
  • Remove pictures from UI as soon as they get uploaded.
  • Better reporting progress to the users for time consuming operations.
  • Allow specifying a list of pictures to be loaded from command line.
  • Register frogr as image mime types handler, so it’s possible to load pictures on it from other applications (e.g. nautilus or eog).
  • Improved keyboard usability by adding mnemonics, making text views not to accept tab and enabling the menu key in the icon view.
  • Nine new translations (see TRANSLATORS file for details).
  • As usual, lots of bugfixes and several minor improvements.

From a more practical point of view, let’s just say that Frogr 0.4 is the first “serious” release, in the way that it should provide a fairly good amount of features for the average Flickr users to feel comfortable using it for their typical use cases. Nevertheless, development won’t stop here so don’t hesitate to contribute with the project if you feel like doing it, either by proposing ideas, translating, coding, discussing or even by filing or fixing bugs.

As usual, you can get it through different ways:

Hope you like this tiny little application. For more information, just check out its web site.

Ah! And as everybody loves screenshots (tm), here you have one composition of several of them  so you can realize how it looks now in my desktop:

Frogr 0.4 screenshots

Some updates on frogr 0.4 and myself

Published / by mario / 3 Comments on Some updates on frogr 0.4 and myself

Too many things have happened to me during the last weeks (some good and some bad, as usual), but I still have found some time to continue improving frogr towards the 0.4 release, which I hope it’s gonna be, at least thinking of my very particular use cases, a very complete and functional release. Still, the UI won’t be great (I’d really need help with this), I know that… but I said “complete and functional”, right? I do not remember having mentioned “beautiful”, “eye candy”, or the like… that’s a matter, though, I’ll probably consider for following releases, but not for now.

The point of this post is that I declared yesterday the official start of the feature & string freeze phase for frogr, which basically means that what you can find in the NEWS file is exactly what you’ll find in the next release (which should happen in 2-3 weeks time), and that the awesome people in the GNOME translations teams can now work on adding new translations, or just updating the ones already present in the Damnes Lies platform, without having to worry about the strings changing again before the release.

Another thing I’d like to publicly say here and now, and which you might have already noticed from the previous paragraph, is that this release is gonna be the first one after having moved frogr to the GNOME infrastructure, which basically means that its previous site and mailing lists at Google Code, as well as the old repository at gitorious, are now deprecated in favour of live.gnome.org, GNOME’s bugzilla and GNOME’s git repository. And this, at least in my very personal opinion, is really great news for frogr, and I’m really happy about it.

Other than that, but related, last week I’ve finally decided to apply for the GNOME Foundation, and got accepted, which was also great news for me, since it was something already in the back of my mind for some time, and I guess I just needed a ‘trigger’ for daring to apply for it… and moving frogr to GNOME, together with all the a11y related work I’ve been doing during the past months in WebKitGTK+, as part of the WebKit team at Igalia, were actually good ‘triggers’ for that.

So a big ‘thank you’ to all who helped making all that possible, specially to Claudio Saavedra for encouraging for doing this moves, and to Christer Edwards, who kindly attended all my continuous requests to perform all the related tasks in record time.

By the way, as Claudio and some other workmates, I’ll be attending to FOSDEM once again this year thanks to the support from Igalia, where I’m starting to have a hard time sometimes to explain that the Beer Event has nothing to do with me willing to go every year :-).

Anyway, apart from hanging around the venue, I’ll also be giving a talk about a11y in WebKitGTK+ in the accessibility devroom on Sunday, so that makes another pretty good reason for me to go this year. So, you see? It’s not only about beer!

Update [05/02/2011]: At the end, and due to unexpected and very important personal matters, I was finally not able to attend FOSDEM. Hopefully I’ll be able to go next year, but as for now I’d like to wish all the attendants of the 2011 edition have a great time there and enjoy this awesome meeting, which is one of my favorite ones every year.

The family keeps growing

Published / by mario / 12 Comments on The family keeps growing

The Family

Quick after-Christmas post to tell the world, now that is not a secret anymore [*],  that Isa, Sergio and me are currently expecting a new member to “arrive” in the family by next summer,  still no idea whether it would be a boy or a girl, but whatever it will be, we’re already happier than ever, suspiciously in a similar situation than almost two years ago, when I told the world about the arrival of Sergio, our first son.

Well… to be honest I couldn’t hide my preference for a girl if you ask me, just in order to get “the perfect couple”, but regardless of that I’m sure I’m gonna be the happiest man in the world. Yes, once again… and this time it’s not just speculation, I already have 2 years of “experience in the field” supporting this assertion, so take it seriously.

So that’s it, won’t write much more because I don’t want to look boring or the like talking about this kind of personal stuff in this blog, but what the hell… it’s the only one I have and I couldn’t avoid using it to share this publicly.

I think that’s all for now, and sorry for the very-likely-too-personal stuff in my blog.

Happy new year!

[*] You know… even in the era of Internet it kind of makes sense to me to tell these kind of news to some people first before broadcasting them to the world.

Frogr 0.3 released (hello, flicksoup!)

Published / by mario / 10 Comments on Frogr 0.3 released (hello, flicksoup!)

After more than one year without writing almost anything related to my other pet project “frogr“, I finally found some time, motivation and energy to put all the loose parts I already had more or less in place together and evolve them towards what finally made a new release of this -yet another- GNOME flickr uploader.

That way, I finally released frogr 0.3 two days ago (see the announcement here), featuring the following changes:

  • Replaced flickcurl (synchronous, libcurl based) with flicksoup (asynchronous, libsoup based) as the backend library for dealing with the Flickr API.
  • Improved authentication process and made it more “seamless”, so the application is more aware now of the potential issues that might happen, reporting them to the user if needed (e.g. asking the user to re-authorize the app).
  • Better error handling and reporting, not only about the authorization process but about everything about the user-flickr interaction, which made it way more user-friendly (e.g. quota limit exceeded, host unreachable, process cancelled by the user…).
  • Added support to allow cancelling uploads (no more closing the application if forgotten to do something before pressing ‘Upload’!).
  • Added support to allow setting pictures to be added to albums after the upload process. So far, only adding to already existing albums is available, but for the next release allowing the user to create albums on the fly is also planned.
  • Menubar redesigned, so no options get hidden in the contextual menu (did you know there was one?).
  • Updated translations… errr… well… updated THE only translation we have so far (es_ES). Doesn’t it make you feel like tranlating frogr to your beautiful language? C’mon, it’s a really small file with just a bunch of strings!.
  • Simplified code both in frogr and flicksoup, which should ease a lot future enhancements in next releases of frogr, as former design was blocking quite a lot of things until I changed it once and for all.
  • Lots of bugfixes and several minor improvements.

From the point of view of the end user, perhaps it’s a bit strange to even mention the flickcurl/flicksoup change in the list of features above, but I couldn’t help it since that was the biggest change since 0.2 and what I consider the most important one, since it allowed (or just helped a lot, as you wish) that the rest of points actually happened in the way I thought it would be the right one: through a GNOME-ish library which would allow implementing asynchronous operations without the need of using threads (thanks to the mainloop and implementing the methods using the GIO’s GAsync functions), as well as properly reporting errors through GErrors, as it’s commonly done in these kind of applications.

I must say flickcurl is still a great C library which currently implements 99% of the remote flickr API, but for this project I found it too complicated and limited for the kind of things I’d like to do in frogr, which was leading me in many ocassions to work things around in many ways that wouldn’t be necessary if it was a GObject library based in libsoup, instead of a C library based in libcurl. And that’s why I decided to start its implementation, back in February 2010. Unfortunately, the library is not mature enough yet to be separately released, so for the time being I’m just developing it along with frogr, so I can at least release the application, and keeping the intention of release it separately at some point in the future. Still, you can grab the latest code from its own repository if you want to use it separately, where I regularly dump all the changes I do to it through frogr. But I must warn you, it just implements a few functions so far, those strictly needed by frogr, so don’t expect a complete libsoup based version of flickcurl yet, which is far more mature and full of features than this one.

[UPDATE 03/06/2011]: Today I removed the flicksoup repository from gitorious since the truth is that at the moment is not an independently maintained library and what I was doing at the end was (i)regularly dumping files from frogr repo to the flicksoup one. And this, apart from being tedious and usually out-of-sync, was also an issue from the point of view of some distros (like Fedora) when it comes to package frogr, so I decided to go ahead and remove it for the time being. Hopefully in the future flicksoup will be released as an independent library, but as for now it is just part of frogr (although I will keep the whole picture in mind when developing changes for flicksoup inside of frogr). More details in this bug

As usual, you can grab frogr through different ways:

So far, there are only a few of pre-compiled 32-bit packages for ubuntu and fedora in there (those I generated myself, basically), but hopefully this manual effort could stop being needed at some point in the short terms thanks to the efforts of my mate at Igalia Alberto García, who kindly already packaged for debian and asked for its inclusion in the project. Thanks, Berto!

WebKitGTK+ hackfest 2010

Published / by mario / 8 Comments on WebKitGTK+ hackfest 2010

After the daily reports written by Diego in his blog, few more things can be told about the WebKitGTK+ hackfest hosted at the Igalia offices last week, but I’d like to comment anyway some impressions from my personal point of view, if you don’t mind reading them.

First of all, this was the second time I attended to this hackfest (I “kind of” attended last year hackfest as well) but now things were pretty different for me, basically because one year ago I was not part of the Igalia WebKit team yet, hence my contributions in the hackfest were pretty small (see my post back then for more details). However, this time I attended full-time to the event and I must say I’m really proud of the work I’ve been doing right there, which I hope will eventually lead to the resolution of this WebKit metabug, which was about fixing bugs blocking ORCA support from WebKitGTK based applications.

But fortunately, the work I’ve been doing during the last week was just a pretty small and humble contribution compared to all the work that has been done by the rest of the people attending to the hackfest, like fixing GTK3 and GObject Introspection issues, fully integrating in libsoup all the new cache stuff written for WebKitGTK (which eventually lead to removing the equivalent code from WebKitGTK, as my mate Sergio told some weeks ago, as soon as some bots upgrade to the latest version of libsoup), adding support for profiling in JavascriptCore, implementing some missing and advanced features into the DumRenderTree (aka DRT, the so beloved tool for writing functional tests), fixing spell-checking support… and bugfixing in general (as well as, most likely, lots of other things I’m failing to recall right now). You can read Diego’s blog for more details on those.

Other than that, there was also time for working in Epiphany were some notorious fixes and improvements also happened. Those I can remember right now are the new error pages for epiphany, the implementation of a certificates viewer and new font preferences, getting rid of GConf in epiphany-extensions and general bugfixing tasks. As you can easily understand, as the devoted and committed Epiphany user that I am, I’m pretty excited with these improvements as well. Not needed to say anything about this patch committed at the beginning of the hackfest, I guess, in my opinion this is one of those cases where a picture is clearly worth a thousand words:-)

hackfest mooded epiphany

So, as you can see it was a quite productive week after all here in Coruña!

Last but not least, I’d like to specially thank The GNOME Foundation for sponsoring the event, as well as Igalia and Collabora for helping make this possible once again. Hope we can repeat it next year, and that more people will join the event to help making WebKitGTK an even better web engine for the GNOME platform.

See pictures of the hackfest here: