Frogr 0.7 released

Posted on by

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

Posted on by

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+

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Frogr 0.5 running in GNOME 3

An unexpected e-mail

Posted on by

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

Posted on by

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