Category Archives: GNOME

Accessibility in [WebKit]GTK+

Published February 3, 2013 / 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

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:

As 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:

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:

UI Process: basically, the ATK object associated with the GtkWidget provided by WebKitGTK+, that is, the WebView.
Web Process: the whole hierarchy of ATK objects wrapping the accessibility objects from WebCore.

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:

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-SPI, ATK, 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 January 12, 2013 / 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+.

As 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!

Frogr 0.8 released

Published December 29, 2012 / by mario / 5 Comments on Frogr 0.8 released

During the last weeks, I decided to make the most of some spare time I had while still in “nowhere land” (see my previous post) and so I’ve been working in frogr to see if I could release the 0.8 version before the end of the year. In my mind it looked like kind of a nice and humble Christmas present to the world and, at the same time, a interesting way to spent this time I had between my depart from my previous job and the start of the new one.

And it turns out that, at the end, I didn’t manage to have as much spare time as I initially expected to have (I was pretty busy most of the time, actually), mainly due to many unrelated things I needed also to take care of, but in the end I still managed to steal some minutes here and there and I’m now proudly announcing that the new release is finally out.

But before going on, see the mandatory screenshot, as taken in my Fedora 18 machine:

As you can already spot in the screenshot, some changes are already quite visible, but some others are not, so let’s now comment on the most important ones, one by one…

Ported to GtkApplication and GMenu

It’s no secret that one of my favourite changes in this release is the integration with GNOME 3‘s “global menu” (aka the application menu), which makes frogr more beatifully integrated with the desktop than ever. However that came with a price: I needed to port frogr to GtkApplication first and then implement both the application menu and the menu bar using GMenu, which also made me raise the required version for GTK+ up to 3.4.

Sure I could have kept adding more ifdefs to the code to keep supporting previous GTK+ versions, but I also saw this as a good opportunity to clean up the code and get rid of so many conditional compilation units that were increasingly harder to maintain, and so I did it. As a plus, the OS X specific code has been reduced enormously as well, since GTK+ 3.4 integrates very well with OS X without having to do anything special, as I needed to do when I used GTK+ 2.24 for that port.

Loading and saving ‘projects’

This has been one of the features that several people have suggested in the past in different occasions, and so one of those I hope people will enjoy the most with this new release: the possibility to save the current session into a “project file”, so you can resume your work later.

How it works it’s actually pretty simple: when you save a session to a project, frogr will just serialize your current pictures, sets, groups and local tags to a json file (using json-glib) that you can use to restore the state later. It could be more sophisticated, but I think that it works reasonably well in the tests I did considering what it was designed for. In any case, please feel free to report bugs or feature requests to improve or fix things if needed.

Support for video uploads

Believe it or not, frogr has been almost ready to upload videos since some time ago, since for Flickr a video is just a “moving picture”, and it’s treated in exactly the same way than pictures when it comes to the upload API.

The only thing that was missing to remove that almost from here was to generate thumbnails for videos so they could get loaded into the UI. Not rocket science, sure, but something which needed doing and which was not a priority at all until now. And to be honest, it is not a priority yet anyway, but I felt like doing it this time once and for all, so from now on you can upload videos too.

Other features & bug fixes

Besides those three and perhaps more noticeable features, frogr 0.8 comes with several other new things, bug fixes, small changes and refinement that I hope will make this release more stable, useful and fun to use than ever.

Some examples of those other new things are, as taken from the NEWS file:

Handle and report errors in a better way (no more mysterious failures).
Perform after-upload operations (add to sets/groups, set license…) in parallel.
Avoid fetching sets/groups/tags when still not connected yet to Flickr.
Hide title bar when main window is maximized (see screenshot above).
Renamed the ‘Actions’ menu to ‘Edit’ and brought the ‘File’ menu back.
Allow sorting elements in the icon view by size.

Last, I’m also quite happy to tell that the OS X port of frogr has been finally migrated to GTK+ 3 in this release (at last!), and that the whole process of building it for that platform is now easier than ever, thanks to a specific Jhbuild moduleset I created for that purpose, following the lead of GEdit (thanks Nacho for the suggestion).

Check out the README file in the osx/ directory if you feel curious about the process or if you want to build it yourself. It shouldn’t take more than 2-3 commands in the terminal to get something like this running in your OS X machine:

Also, another advantage of having that moduleset created, is that now it’s trivial to properly document (by means of a shell script) the bundle file used to distribute frogr in OS X, instead of just providing an “opaque” pre-compiled bundle, as I used to do in an “unofficial way” with previous versions. Feel free to grab the bundle I’ve just created for this release from the GNOME FTP server.

So that’s it. I hope you enjoy using frogr 0.8 as much as I did writing it, and if you eventually find it useful too, then even better! As usual, check the website of the project for additional information or just to know how to install frogr on your system.

Moving On

Published November 19, 2012 / 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 September 14, 2012 / 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 July 20, 2012 / by mario

It 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.

Frogr 0.7 released

Published May 23, 2012 / 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.

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 February 1, 2012 / 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 January 27, 2012 / 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), yelp, liferea… 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 December 6, 2011 / 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.

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.

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 November 11, 2011 / 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 August 19, 2011 / 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 August 13, 2011 / by mario / 8 Comments on Frogr 0.6 released

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

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:

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 May 27, 2011 / 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:

Source code: clone from the git repository at gnome.org.
Tarballs: both in xz and bzip2 formats.
Pre-compiled packages for Fedora: at my personal public folder in gnome.org.
For the specific case of Ubuntu you can use this PPA at LaunchPad.
MacOSX packages (Intel) in the GNOME FTP server (experimental, yet ready for everyday use)

[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, translating, coding, discussing 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:

An unexpected e-mail

Published May 11, 2011 / by mario

Today, while at the ATK/AT-SPI hackfest, I received a mail in my INBOX from a well known guy from the GNOME community stating just the following:

Don't know if you read Hackers news, but this one is pretty nice:
http://news.ycombinator.com/item?id=2532790
--
Regards

So I followed the link and I found a nice thread titled “Love in GIT” where people were commenting about something which remind me of one of the last commits I did in frogr, which became my favourite one so far in the project, by the way.

But the big surprise for me came when I realized that the thread was actually about the commit I innocently made last week, when I realized that the so-much-important THANKS file was outdated since almost one year ago, right when I got married, so I decided to update it. Then I understood that there was actually a good reason for the thread to remind me of that change… Yes, I know, sometimes I’m “a little bit too slow” :-)

So I’d just like to publicly say thanks to the misterious-but-well-known-hacker that sent me the e-mail for making me draw a big smile on my face, and to the people commenting in that thread for the so nice (and funny… “make babies”??) messages posted in there.

Thanks!

Update [2011/05/12]: Now it seems the whole thing hit LWN… hilarious!

WebKit Contributors Meeting, sockets & plugs

Published May 5, 2011 / 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.

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).

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:

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

Frogr 0.4 is out!

Published February 5, 2011 / 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:

Source code: clone from the git repository at gnome.org.
Tarballs: both in gzip and bzip2 formats.
Pre-compiled packages for most common distros: at the web of the project.

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:

Some updates on frogr 0.4 and myself

Published January 22, 2011 / 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.

Frogr 0.3 released (hello, flicksoup!)

Published December 24, 2010 / 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:

Source code: clone from the git repository at gitorius.
Tarballs: from the web of the project, in gzip and bzip2 formats.
Pre-compiled packages for most common distros: at the web of the project.

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 December 13, 2010 / 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:-)

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:

mariospr.org

Ramblings from the dark side of the moon