Gustavo Noronha (kov)

When I started working on WebKitGTK+ I was a web developer, writing IT applications using Python and Django, and building features for content portals running Plone (argh). Even though I was an Epiphany user ever since it was forked off Galeon, I still had to use Firefox for my work, because I couldn’t really live without Firebug.

It should come as no surprise, then, that one of my first patches to WebKitGTK+ was actually making the awesome Web Inspector work in our port. After the initial support, though, not a lot has been done to further improve it, partly because it was already good enough for many uses, partly because I somehow started doing non-web development again ;).

These last weeks, through my R&D efforts in Collabora, I have been able to push Web Inspector features and integration a bit further. A simple change that boosts the Inspector’s usability quite a bit is having the nodes that are being hovered highlighted. Along with that, the ability to attach the inspector to Epiphany’s window should make it easier to use for poking the DOM.

The Web Inspector has a number of settings that control its behaviour. Since, for instance, enabling javascript debugging may slow down javascript performance, the inspector usually has it disabled by default, and provides a button to enable it. It also provides an option for always enabling that feature, but that does not work right now, because we are not saving/restoring the relevant settings. A solution to that is in the works using the GSettings infrastructure that was recently merged into glib.

Here’s a simple screencast, showing these improvements in action (click the video to check it out in full size):

Some of you may have noticed WebKitGTK+ 1.2.2 and 1.2.3 have been uploaded recently. Here’s their announcement =). A quick summary: if you’re running the 1.2.x series upgrade to 1.2.3.

Here’s some information regarding 1.2.2:

1.2.2 is an update to the 1.2.x stable series; along with a lot of crash, and misc fixes the biggest changes are: 1) the inclusion of a new API from the development branch (webkit_back_forward_list_clear()),
because it’s simple and will help with fixing a problem in Epiphany stable, and 2) lots of drag and drop, and clipboard related work by Martin Robinson.

Despite not being strictly fixes, we believe the stable series has a lot to gain from this work; a couple examples should illustrate this better: the changes included fix both a crash when dragging links from WebKit into other browsers, and the annoying bug that made the cursor get stuck in a grab when dragging, sometimes.

http://webkitgtk.org/webkit-1.2.2.tar.gz
MD5: 40338001324a38b977c163291e8816d3

Here’s some information regarding 1.2.3:

To some such a quick succession in releases may look like a brown paper bag was in order. Not strictly, but indeed 1.2.3 aims to fix some oversights with easy fixes. First of all, WebKit was not buildable with ICU 4.4.1, but thankfully a fix had already been checked in to trunk, so 1.2.3 includes that fix. Secondly, Debian’s Michael Gilbert has done a great job going through all CVEs released about WebKit, and including patches in the Debian package. 1.2.3 includes all of the commits from trunk to fix those, too.

http://webkitgtk.org/webkit-1.2.3.tar.gz
MD5: 0ab5c478a6f5b74a1ae96bf13a456662

You can read some more details, including the list of CVEs that were addressed, in the NEWS file:

http://gitorious.org/webkitgtk/stable/blobs/master/WebKit/gtk/NEWS

Enjoy!

Have you ever seen, while dealing in a support channel with a novice that just got in touch with the power of UNIX a conversation that goes like this?:

<novice> How can I process the output of a command, so that any number of spaces gets turned into a newline?
<seasoned> What are you trying to do?
<novice> I want to list the contents of a directory, but I want one per line.
<seasoned> ls -1

I have seen this numerous times, even as one of the actors. At times I was the novice, and many times in #debian-br I was the seasoned person trying to get the novice to focus on the problem they were trying to solve, not on the solution they thought was right.

While reading Máirín Duffy’s awesome paper about contributing to Free Software as a designer I couldn’t help but get that image brought to my memory again, and again. Specially when I read this part:

This means the language and even the approach FLOSS projects take to solving problems tend to be focused on implementation and technology rather than starting with a real-life user problem to solve and determining appropriate implementation afterwards.

That does sound like us, and it does sound like many of the solutions we come up with. While I was reading her paper, there was a reference I got very interested in checking. It’s a PDF with no links in it, so I only had the number of the reference. What I would have to do is I would have to scroll to the end of the paper, and find the reference, then somehow come back to the place I was looking at.

My most immediate thought was ‘you know, maybe evince should have tabs’. Why? Because I could open a new tab, go to the place the reference was at, and to ‘go back’ I just needed to close the new tab. Other options require much more effort - remembering the page I was at, or maybe the scroll offset more or less, and scan for the part of the text I was at. But those are not the only options! I could have the application set a marker on where I am, and have an easy command to go back to that marker, for instance, or evince could provide a way of ‘looking ahead’ without throwing away the current state at all. I’m pretty sure if I look around enough I will find tools that solve this problem in a fairly good way.

Now, I think that is exactly how we ended up with tabs in so many places they do not make sense in, and with so many ad-hoc solutions that solve our problems in half-assed ways. Even in browsers, we tend to use tabs as ad-hoc solutions to real problems we have no real solution to handle yet, such as “I want to check this other thing out real quick, but I do not want to lose any state of this page”, or “I want to check this out, but not right now, so let me open it, and then I’ll come back to it”, or maybe even “I want to look at this now, but since it is going to take a while to load, I might as well let it load in the background, and when I finish reading this I can go look at it”. These are the real problems we have, and I think we need better designs that solve them for real, instead of just patching them with the ad-hoc solution that tabs are.

The other extreme of the spectrum is, of course, not doing something, or even anything for lack of the perfect solution. Using ‘this is not a real solution’ as an excuse to not implement something that could serve as a temporary solution to a problem may cause more frustration than having to deal with the ad-hoc solution that is tested, and being applied to other applications for some time. After all, in many cases the ad-hoc solution can be later replaced with a proper one.

I guess this is another instance of the very difficult problem of balancing different realities: proper design is not always available to start something up, specially if the application is backed by individuals and not by a company or a bigger project that could bring in designers to work on it from the start. In this case having something up and running is usually a very important first step in a free software project - usually required to get enough interest to make it worth designing for.

We’re coming close to GNOME 2.30 release date, and we are getting ready to branch a stable release off of WebKit’s svn trunk in preparation for that. The idea of the stable branch is to try to maintain, and improve stability, with no additional features going in. Speaking of features, though, if you’ve been paying attention you will have noticed WebKitGTK+ has come a long way, now.

We came from not having basic features such as download support or openning links in new tabs, a more-or-less working HTML5 media implementation, and very few or missing in action developers to a thriving project, that gets more, and more attention, and contributors every day, with advanced features available, and rocking HTML5 media support that leaves little to be desired. It’s been just over one year since we started rolling mostly bi-weekly releases, each adding more awesome features.

There are still many issues, and we are not always equipped as a team to handle all the specifics of the engine ourselves, but I am really happy with the progress we’ve made, and really thankful for the support my employer Collabora has given all the way for this to happen, including the early work on plugins, and many other things before my time as a contributor. When I switched to using Epiphany with the WebKit backend as my default browser back in January 2009, that meant having to deal with a whole lot of misbehaviour, and work-around a lot of painful brokeness. These days I enjoy a snappy, functional browser that makes me happy.

If you haven’t done so yet, go download, and test the newest Epiphany, with the latest WebKitGTK+, and help us make the GNOME 2.30’s web browser rock even more!

The WebKit hackfest is now over, and I think it was a very productive week. Thank you very much to all who attended, to Igalia for organizing the hackfest, and hosting us so well, to Collabora for having sponsored the event, and allowed me to spend the week working on it, and to the GNOME foundation for having payed all of my costs!

Xan blogged about day 0, and also a summary of all that was done, so I’ll focus on the stuff he forgot to mention ;D. The hackfest, for me, started on day -1 with me not allowing Xan to go sleep before he had reviewed a couple patches of mine to fix DOM context menu handling. It always bothered me that Epiphany failed to open right-click menus in some pages, or let pages handle the right click. Well, this is fixed now, and Zimbra users can now have their right click menus, and WoW players can remove talent points from their calculators =P.

It turns out that many of the attendees don’t like pages messing with their context menus, though, and they had some good points to back up their positions (like pages making it hard to save images, for instance), so I implemented a way to force openning the custom menu: Ctrl-rightclick.

We wanted to use a GtkInfoBar to display questions regarding the form saving - our initial implementation always saved all credentials, but that didn’t sound good enough. Xan and I thought it would be very complicated to make this work, because there were assumptions in the code regarding which widget contains which, but it turned out to be quite trivial - making EphyEmbed a descendant of GtkVBox instead of GtkScrolledWindow, fixing a small number of assumptions, and that was it.

The passwords are saved in the GNOME Keyring. It’s interesting to point out that GNOME Keyring seems to be unhappy with the number of passwords a browser stores - Xan’s daemon was hanging, crashing, and spawning a large number of threads. My daemon decided to take up some 300MB of RAM at one point. It’s somewhat funny to see how much a browser pushes the limits of our platform. We are hoping this will improve with the new keyring APIs, and the rewrite that is ongoing. It’s nice to see my browser form passwords in seahorse, though, and be able to manage them like any other.

One more thing worth of notice, although this post is already a bit too big: one of the main concerns people had during the Hackfest was on making build time smaller. Touching a single file in WebCore causes a debug build of 10 minutes on my laptop. Evan Martin and Benjamin Otte made a push at removing unnecessary includes from WebCore, and WebKitGTK+ files, which brough the build time down a bit. They end up inspiring Aroben, from Apple, to go even further into this, and remove many includes from files all over WebKit.

Evan was also able to bring linking time down by making it possible to link libwebkit without having to build all the intermediate libraries, which brought build time down to 1 minute, when touching a single file in WebCore. Behdad and I also started looking into breaking WebCore up into lots of shared libraries for Debug builds, since we don’t care too much about speed penalties in those. None of these experiments got committed yet, but I am hoping we will be having a better time hacking on WebKitGTK+ in the near future.

It was awesome meeting everyone, by the way! See you around =).

There are few things I really hate. One of them is regressions. Regressions are bad because they usually take away things we are used to rely on, and leave us with the idea that perhaps the technical improvements didn’t really improve our lifes as a user, despite putting less burden on the developers. Software is made for users, after all.

As part of my work on WebKitGTK+, I always keep an eye on regressions, both from previous WebKitGTK+ releases, and those imposed on embedding applications on their migration away from Gecko, and try to focus some of my efforts into lowering their numbers, whenever I can.

In recent times I have worked on removing a few very user-visible regressions in Epiphany, which I see as the most demanding WebKitGTK+ user in GNOME, such as save page not working, missing
favicon support, failing to
perform server-pushed downloads (such as GMail attachments), and not being able to view source. An example of a regression from a previous version of WebKit also exists: in 1.1.17 we started advertising more than we should as supported by the HTML5 media player, causing download to be almost completely broken.

All of these are working if you are using WebKit and Epiphany from trunk/master, so should be on the next development versions of WebKitGTK+ and Epiphany. Other people have also fixed many other regressions; a few examples: Xan has reimplemented the Epiphany customization of the context menu, Frederic Peters provided a work-around for mailto: links while we don’t have SoupURILoader yet, and Joanmarie Diggs keeps rocking on the accessibility front!

If you find regressions, keep them coming! If you have a patch, even better! =)

Next week WebKitGTK+ team gets together to work furiously on improving WebKitGTK+ in a hackfest sponsored by Collabora, and Igalia, and hosted/organized by Igalia. While there I should also get my hands on one of these. Can’t wait! =)

Here are some notes about my experience with GCDS:

Spain is a very interesting country. My impression regarding Las Palmas matches that of Lucas, by the way, that it looks very similar to Salvador, although it’s more windy, and also very greyish/brownish. Some of the buildings are very similar to buildings you would see in Brazil, too. It was the first time I saw wind turbines for power generation.

The conference was really good, in many ways. Thanks to those who organized it, and also to all those who attended it! I had never been to a GUADEC before, so I don’t really have an idea of how GCDS compared to previous GUADECs, though =). Before I speak more of what I enjoyed, some notes about what I disliked: the organization seemed to be a bit improvised at times, I would have preferred that the university be the only venue, and the networking infra-structure lacked - you could hardly get a connection that worked, and I kept getting disconnected. Comparing those points to the other conference I usually go to which is comparable in size and complexity (Debconf), GCDS leaved a lot to be desired.

Now for the good points: most talks were very in-depth, and of high quality, the fact that KDE people were around meant it was a great opportunity to share, and discuss. I was able to meet lots of people I have talked to only on IRC, not only from KDE, GNOME, and WebKit, but also many work colleagues =). We were many Collaborans going around at GCDS!

I also met long-time friends, and made new ones, which I think is always the most important part of such conferences. I wanted to do so many things that by the time the conference ended, I had this feeling that I did none of them completely. I specially wanted to have spent more time with the WebKit guys, for instance. The parties were always very good, even though I think talking is more important than dancing when you have a lot of geeks around who you are not going to see for a while. I do enjoy dancing, though, and can say the KDE crowd excels in this regard =). I have consistently failed to drink enough to forget about bits of the night, which is good, too!

To sum it up, I really loved coming to this GCDS, and really look forward to taking part on more editions! Now, I’m going to spend some days working at Cambridge, hosted by my colleagues Marco and Alban (thanks!), and then I’ll be showing up at debconf9 with some more Collaborans. Fun times ahead!

Well, not really my first patch. But the first thing I tried to mess with when I first started looking at WebKitGTK+ was the WebKitNetworkRequest object, because I was fancing the idea of writing stuff such as HTTP transactions monitoring, and things like that. So I wrote a big patch which exposed the internal WebCore object (ResourceRequest) fully through our own object. That was back in early 2008. We have come a long way since, and through all these months I got a broader perception of what kind of APIs we need, and how WebCore works. We also decided on going soup-only, which had a huge impact on what the final patch actually looks like.

The patch which finally got committed this week is, how can I put it, VERY different from what I had originally written. You can take a look at the long discussions about it in the bug report I used to track progress. I think I should point out that Marco Barisione and Christian Dywan were crucial in helping me get going with my contribution to WebKit at that time.

What this change gives us is basically the fact that a WebKitNetworkRequest now carries more than just the URI for the request (it actually carries with it a reference to the SoupMessage that will be used later in the request processing, which we are planning to expose in the near future), meaning that when WebKit API gives you a request, and you use it to cause a new load (for, say, opening in a new tab), you still get all the headers that were supposed to go with the request, so you don’t lose things such as, for instance, Referer. So, now, after more than 5 years, the bug that complained that Epiphany did not set Referer (and Galeon before that) for new tabs is finally closed.

By the way, this problem has been fixed for Mozilla’s browser back in 2002, but the embedding API is still buggy up to now. There is still hope, since there’s an attached patch that fixes the issue to be reviewed, and landed. If anyone is reading, it might be a good oportunity to get this fixed in there as well, so that users of applications that use Gecko’s embedding API can also benefit!

So, I just checked in for attending Bossa Conference. If you want to talk about Debian, WebKit, WebKitGTK+, Gksu-PolicyKit, I’ll be quite interested =).

Então. Eu vou. =)

Há quem esteja dizendo que a conferência é uma inundanção de palestrantes relacionados a KDE e Qt, o que é próximo da verdade, muito embora eu esteja ansioso para conhecer alguns GNOMErs que já vi que estarão lá. De qualquer forma, essa talvez seja uma boa oportunidade para eu comentar o que eu achei do recente lançamento da Qt 4.5, com a licença LGPL.

Quem já me conhece sabe que eu não morro de amores nem por C++, nem por KDE. Então muita gente (que gosta de KDE) veio correndo me dizer como agora GTK+ tinha acabado, provavelmente imaginando que eu estava achando ruim a notícia. Engraçado que um outro amigo me disse há mais de um ano que GNOME ia acabar com o lançamento do KDE4 =). Antes de mais nada, comparar Qt com GTK+ não faz sentido. A GTK+ é um toolkit gráfico e widget set razoavelmente limitado. A Qt é um pacote enorme, com funcionalidades de todo tipo, incluindo coisas como banco de dados, rede, XML, svg, 3D, renderização web, entre outros.

Mas é importante lembrar que a maioria dessas características existe sim para desenvolvedores GTK+! Então, eu acho mais sensato comparar Qt com o ‘mundo’ glib, que inclui coias como a libsoup, o gstreamer, GDA, WebKitGTK+, Clutter, e por aí vai. Eu não acho que exista um ganhador absoluto e imediato em uma disputa por espaço, nem acho que o fato de a Qt ter sido lançada como LGPL vai afetar tão negativamente o mundo glib como parecem acreditar alguns. GNOME continua sendo dominante no desktop livre, e além de GTK+ existem, como eu disse, diversas tecnologias de qualidade, e a facilidade de criar bindings significa que ainda existem mais bindings feitas para tecnologias glibicas, com auto-geração de bindings para qualquer biblioteca baseada em glib muito próximo de ser realidade.

O mundo Qt também tem diversas tecnologias bem-feitas ao seu redor, e eu respeito muito os times que geraram projetos como Nepomuk e KHTML (que serviu de suporte para o WebKit, em que eu trabalho bastante hoje). E eu acredito que nós vamos continuar a ver as tecnologias dos dois mundos se aproximando e se complementando.

E Qt ter sido lançado como LGPL, e, principalmente, passar a ter um modelo de desenvolvimento de comunidade, é uma ótima notícia! Isso significa que a colaboração entre as tecnologias fica facilitada, e que o projeto KDE (e outros projetos livres, inclusive do mundo glib!) não precisam ficar marginalizados com relação ao desenvolvimento da Qt (o fato de o pessoal do KDE ter que manter um pequeno fork da Qt era triste, por exemplo). E a Qt continua sendo livre, assim como o KDE, o que já é suficiente para que eles sejam considerados aliados, para mim. Então, all the power para Qt 4.5!