WebKitGTK+ HackFest!

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

Regressions, ah, regressions

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!

My first patch to WebKitGTK+ committed!

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!

Bossa Conference

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!

Web Inspector for WebKit/GTK+

Some weeks ago I read an old blog post about the WebKit Web Inspector having been done for the Qt port. I didn’t know the web inspector at the time, but I loved what I saw. WebKit’s Web Inspector does look nice, and I thought it could finally replace Firebug as my main web development tool.

Since I have been contributing some patches to the GTK+ port of WebKit, I thought I would be able to understand and implement the Inspector. And so I did it. I’m still waiting for further comments, and its current form may not be final, but it works, and I’ve been using it for small debugging needs for a project I’m currently involved here at AlfaiaTI. Some screenshots:

The Inspector tracing some dumb javascript code I am writing

The Inspector showing load time for the various objects of GNOME's web page

Detailed information on a resource downloaded to render the GNOME web page


So, it seems like lots of people are enjoying adding tab support to GNOME applications.

While looking at the screenshots what came to my mind is that this seems just so wrong. I wonder if it is not better to improve task switching in the window manager, pager and window list, and have one window per document, as would be natural in a document-centric desktop.

Why are people trying to ressurrect the MDI model, which the GNOME HIG despises?

In other news, good to see planning on GNOME 3.0. And it does look like people are aware that repeating KDE 4/GNOME 2 is not a good idea, and planning the breakage/delay to be limited, and sane.

Update: a conversation at #webkit-gtk@Freenode just made me realize that the tabs for the calculator and totem were probably just jokes; I really hope so! =)

Lancelot, KDE e GNOME

Eu passei a assinar o Planet KDE. Por quê? Porque eu me interesso pelo que acontece no KDE, e quero entender o que esperar do time do KDE no futuro próximo. Uma das coisas que eu vi me fez querer tirar da lista de drafts um post que escrevi no FISL e nunca cheguei a postar. O que eu vi foi um post sobre o Lancelot, um novo menu que está sendo projetado para o KDE4.

O post parece que foi feito para demonstrar o quão irrelevante o KDE está se tornando do ponto de vista da ‘casca’ do desktop livre, e o quão vapourware o KDE4 ainda é. E o software sobre o qual ele fala me faz pensar que o KDE está indo talvez longe demais em copiar o Windows, o que só o ajuda a se tornar cada vez mais irrelevante para mim. Vamos ao que eu tinha escrito no FISL:

No último evento das LinuxChix, em que encontrei o KDHélio, no final do ano passado, ele profetizou que o KDE 4.1, juntamente com o Mandriva que viria em seguida, acabaria de vez com o GNOME. Que o GNOME não teria mais relevância, e seria substituído, juntamente com o Ubuntu.

Depois de observar o que houve desde então, e de ter testado o KDE4, e lido um pouco a respeito do que os desenvolvedores pensam eu tenho minha própria profecia: o KDE se tornará um projeto de desenvolvimento de infra-estrutura desktop, focando em frameworks de desenvolvimento que abstraiam bastante as complexidades do UNIX, e dando aos desenvolvedores de aplicações uma camada de nível bastante alto, deixando para trás qualquer foco no desktop.

O “desktop shell” talvez continue sendo desenvolvido, mas muito mais como uma test-bed para as tecnologias em desenvolvimento do que algo que é realmente para usuários finais. O GNOME, por sua vez, deve se tornar cada vez mais (porque já é…) a “cara desktop” de que todos vão se lembrar quando se falar em desktop livre.

Não que eu ache que a infra-estrutura de desenvolvimento do GNOME vai ser deixada de lado, ou perder relevância ou espaço, claro. A estrutura de desenvolvimento do GNOME é muito boa (mesmo sendo menos poderosa que a estrutura QT/KDE em várias áreas) e bem projetada, e continua sendo muito mais modular, e tende a incorporar seletivamente partes das estruturas KDEísticas, conforme elas sejam descoladas dos “pacotões da alegria”, como o kdelibs.

Update: O autor to Lancelot encontrou meu post e fez um post em resposta; vale à pela ler o post e os comentários, especialmente a minha contra-resposta.

Minha mãe é muito linda!

Além de ter insistido fazer a declaração de imposto de renda no Debian, minha mãe estava me explicando hoje que prefere muito o Evolution ao Outlook, porque já se acostumou e porque o Outlook tem um costume muito chato de travar. Dá gosto de chegar em casa e ver o Evolution ou o Epiphany sendo usados pela dona Dalvanôra =D. Wee!