Web Engines Hackfest 2014

For the 6th year in a row, Igalia has organized a hackfest focused on web engines. The 5 years before this one were actually focused on the GTK+ port of WebKit, but the number of web engines that matter to us as Free Software developers and consultancies has grown, and so has the scope of the hackfest.

It was a very productive and exciting event. It has already been covered by Manuel RegoPhilippe Normand, Sebastian Dröge and Andy Wingo! I am sure more blog posts will pop up. We had Martin Robinson telling us about the new Servo engine that Mozilla has been developing as a proof of concept for both Rust as a language for building big, complex products and for doing layout in parallel. Andy gave us a very good summary of where JS engines are in terms of performance and features. We had talks about CSS grid layouts, TyGL – a GL-powered implementation of the 2D painting backend in WebKit, the new Wayland port, announced by Zan Dobersek, and a lot more.

With help from my colleague ChangSeok OH, I presented a description of how a team at Collabora led by Marco Barisione made the combination of WebKitGTK+ and GNOME’s web browser a pretty good experience for the Raspberry Pi. It took a not so small amount of both pragmatic limitations and hacks to get to a multi-tab browser that can play youtube videos and be quite responsive, but we were very happy with how well WebKitGTK+ worked as a base for that.

One of my main goals for the hackfest was to help drive features that were lingering in the bug tracker for WebKitGTK+. I picked up a patch that had gone through a number of iterations and rewrites: the HTML5 notifications support, and with help from Carlos Garcia, managed to finish it and land it at the last day of the hackfest! It provides new signals that can be used to authorize notifications, show and close them.

To make notifications work in the best case scenario, the only thing that the API user needs to do is handle the permission request, since we provide a default implementation for the show and close signals that uses libnotify if it is available when building WebKitGTK+. Originally our intention was to use GNotification for the default implementation of those signals in WebKitGTK+, but it turned out to be a pain to use for our purposes.

GNotification is tied to GApplication. This allows for some interesting features, like notifications being persistent and able to reactivate the application, but those make no sense in our current use case, although that may change once service workers become a thing. It can also be a bit problematic given we are a library and thus have no GApplication of our own. That was easily overcome by using the default GApplication of the process for notifications, though.

The show stopper for us using GNotification was the way GNOME Shell currently deals with notifications sent using this mechanism. It will look for a .desktop file named after the application ID used to initialize the GApplication instance and reject the notification if it cannot find that. Besides making this a pain to test – our test browser would need a .desktop file to be installed, that would not work for our main API user! The application ID used for all Web instances is org.gnome.Epiphany at the moment, and that is not the same as any of the desktop files used either by the main browser or by the web apps created with it.

For the future we will probably move Epiphany towards this new era, and all users of the WebKitGTK+ API as well, but the strictness of GNOME Shell would hurt the usefulness of our default implementation right now, so we decided to stick to libnotify for the time being.

Other than that, I managed to review a bunch of patches during the hackfest, and took part in many interesting discussions regarding the next steps for GNOME Web and the GTK+ and Wayland ports of WebKit, such as the potential introduction of a threaded compositor, which is pretty exciting. We also tried to have Bastien Nocera as a guest participant for one of our sessions, but it turns out that requires more than a notebook on top of a bench hooked up to   a TV to work well. We could think of something next time ;D.

I’d like to thank Igalia for organizing and sponsoring the event, Collabora for sponsoring and sending ChangSeok and myself over to Spain from far away Brazil and South Korea, and Adobe for also sponsoring the event! Hope to see you all next year!

Web Engines Hackfest 2014 sponsors: Adobe, Collabora and Igalia

Web Engines Hackfest 2014 sponsors: Adobe, Collabora and Igalia

WebKitGTK+ hackfest 5.0 (2013)!

For the fifth year in a row the fearless WebKitGTK+ hackers have gathered in A Coruña to bring GNOME and the web closer. Igalia has organized and hosted it as usual, welcoming a record 30 people to its office. The GNOME foundation has sponsored my trip allowing me to fly the cool 18 seats propeller airplane from Lisbon to A Coruña, which is a nice adventure, and have pulpo a feira for dinner, which I simply love! That in addition to enjoying the company of so many great hackers.

Web with wider tabs and the new prefs dialog
Web with wider tabs and the new prefs dialog

The goals for the hackfest have been ambitious, as usual, but we made good headway on them. Web the browser (AKA Epiphany) has seen a ton of little improvements, with Carlos splitting the shell search provider to a separate binary, which allowed us to remove some hacks from the session management code from the browser. It also makes testing changes to Web more convenient again. Jon McCan has been pounding at Web’s UI making it more sleek, with tabs that expand to make better use of available horizontal space in the tab bar, new dialogs for preferences, cookies and password handling. I have made my tiny contribution by making it not keep tabs that were created just for what turned out to be a download around. For this last day of hackfest I plan to also fix an issue with text encoding detection and help track down a hang that happens upon page load.

Martin Robinson and Dan Winship hack
Martin Robinson and Dan Winship hack

Martin Robinson and myself have as usual dived into the more disgusting and wide-reaching maintainership tasks that we have lots of trouble pushing forward on our day-to-day lives. Porting our build system to CMake has been one of these long-term goals, not because we love CMake (we don’t) or because we hate autotools (we do), but because it should make people’s lives easier when adding new files to the build, and should also make our build less hacky and quicker – it is sad to see how slow our build can be when compared to something like Chromium, and we think a big part of the problem lies on how complex and dumb autotools and make can be. We have picked up a few of our old branches, brought them up-to-date and landed, which now lets us build the main WebKit2GTK+ library through cmake in trunk. This is an important first step, but there’s plenty to do.

Hackers take advantage of the icecream network for faster builds
Hackers take advantage of the icecream network for faster builds

Under the hood, Dan Winship has been pushing HTTP2 support for libsoup forward, with a dead-tree version of the spec by his side. He is refactoring libsoup internals to accomodate the new code paths. Still on the HTTP front, I have been updating soup’s MIME type sniffing support to match the newest living specification, which includes specification for several new types and a new security feature introduced by Internet Explorer and later adopted by other browsers. The huge task of preparing the ground for a one process per tab (or other kinds of process separation, this will still be topic for discussion for a while) has been pushed forward by several hackers, with Carlos Garcia and Andy Wingo leading the charge.

Jon and Guillaume battling code
Jon and Guillaume battling code

Other than that I have been putting in some more work on improving the integration of the new Web Inspector with WebKitGTK+. Carlos has reviewed the patch to allow attaching the inspector to the right side of the window, but we have decided to split it in two, one providing the functionality and one the API that will allow browsers to customize how that is done. There’s a lot of work to be done here, I plan to land at least this first patch durign the hackfest. I have also fought one more battle in the never-ending User-Agent sniffing war, in which we cannot win, it looks like.

Hackers chillin' at A Coruña
Hackers chillin’ at A Coruña

I am very happy to be here for the fifth year in a row, and I hope we will be meeting here for many more years to come! Thanks a lot to Igalia for sponsoring and hosting the hackfest, and to the GNOME foundation for making it possible for me to attend! See you in 2014!

Montanha: agora de olho nos vereadores de BH e alguns comentários sobre contribuições

Alguns dos leitores talvez saibam que eu escrevi no meio de 2010 um programa chamado ‘Montanha’. A ideia original do programa era me ajudar a escolher um candidato a deputado estadual me dando uma ideia geral de como os deputados da época gastavam os recursos da verba indenizatória. O site da Assembléia Legislativa de Minas Gerais publica essas informações, mas de uma forma muito inconveniente, tornando absolutamente impossível ter uma idea geral de como os deputados gastam a bufunfa. Obviamente botei o código online e subi uma instância pública para que outras pessoas pudessem fazer o mesmo. Depois disso o grande tevaum se juntou ao time e já adicionamos uma instância para a nova legislatura, que tomou posse em 2011.

Nos últimos dias decidi que com os belorizontinos prestando atenção nos vereadores, dada a polêmica sobre o aumento de salários e o veto pelo prefeito, seria um bom momento para criar o coletor e subir uma instância nova do Montanha, pra observar os gastos dos vereadores. Quem olhar vai notar rapidamente que o projeto ainda está pela metade: ainda faltam informações de partido dos vereadores, os links falam em ‘deputados’ e por aí vai, mas sou fiel ao princípio de release early, release often, então não quis esperar – quando os dados começaram a encher o banco botei o projeto pra fora.

Agora alguns comentários sobre questões que as pessoas me colocam:

Bacana! Se precisar de ajuda tamos aí!

Obrigado! Esse é um projeto de software livre – o código está sob a Affero GPL3 e sua contribuição é bem-vinda. Eu acredito firmemente em outro princípio: talk is cheap; show me the code. Eu não pretendo organizar/coordenar os esforços de outras pessoas, então não espere que eu peça ajuda para algo específico ou pegue na mão, sinta-se à vontade para clonar o projeto, fazer as modificações que achar que devem ser feitas e propô-las, não posso garantir que alguma coisa será incorporada ao meu branch, mas estou disposto a discutir questões de design/planos e responder dúvidas sobre o código – no canal #linux-bh da freenode, principalmente =).

Quais os planos pro futuro?

O meu TODO imediato é (e sinta-se à vontade pra roubar qualquer um e fazer):

  • colocar os dados de partido nos dados da Câmara Municipal de BH
  • mudar a interface do montanha para não falar em ‘deputados’, mas em ‘parlamentares’
  • escrever um coletor para os dados anteriores a março de 2010 da CMBH
  • melhorar a linkabilidade das pesquisas – deixar que você envie um link da visão de todos os gastos, por exemplo, com uma busca já feita
  • escrever alguns posts no Observador Político e no Trezentos chamando a atenção para algumas informações expostas pelo montanha
  • adicionar mais gráficos – gasto sobre tempo, por exemplo
  • melhorar a informação que o sistema dá a respeito do período coberto pelos dados
  • aumentar a quantidade de trivia exibida na página de detalhes de parlamentar
  • criar uma página com detalhes e trivia para fornecedores

Por que você não coloca esse projeto no Transparência Hacker (ou outro grupo)?

A minha resposta para esse tipo de pergunta tem sido ‘por quê eu deveria’? Não é que eu seja um lobo solitário, mas eu acho que só faz sentido participar de um projeto específico se houver alguma razão para tal. Visibilidade não me preocupa muito – a mensagem sempre acaba chegando em quem se interessa e em quem me interessa que ela chegue.

Eu não acredito que participar de um grupo – qualquer grupo – seja garantia de contribuidores, também; como eu disse, talk is cheap e disso eu tenho certeza de que acharia muito num grupo, mas acredito que as pessoas que quiserem contribuir vão contribuir independente de estar dentro de um grupo (como o Estêvão faz). Se um pedaço grande da contribuição vier de pessoas que fazem parte de um grupo e fizer sentido discutir o projeto dentro dele, aí sim eu veria sentido, por exemplo.

Uma última preocupação, essa específica com o thack, é que o foco do grupo me parece muito diferente do meu. Meu objetivo é que a sociedade tenha uma ferramenta para observar seus parlamentares. Para que isso aconteça é preciso que a ferramenta tenha uma vida mais longa e seja mantida. Os dados sobre a legislatura passada da ALMG, por exemplo, já foram retiradas do site da ALMG, mas o Montanha continua lá, a sociedade continua tendo acesso não só a todos dados, como a uma visualização mais razoável deles. Eu não estou prometendo que vou manter pra sempre, claro, principalmente porque faço isso no meu tempo vago (em que eu também trabalho pro Debian, GNOME, como, durmo e me divirto), mas a minha ideia é focar nesse um problema e ter uma boa solução razoavelmente perene.

A maioria das coisas que eu vi do thack são hacks muito bacanas, mas sua vida parece ser muito curta – assim que um hack está pronto outra ideia legal aparece e aquela é deixada para trás; essa bola já foi levantada por outras pessoas, inclusive, como exemplo de por quê grupos como o thack não são a solução definitiva para o problema de dados abertos e de por quê concursos de criação de app não substituem um trabalho sério dentro do governo; não é incomum achar coisas com dados de anos atrás ou que sequer continuam funcionando. Note que eu não tenho nada contra o thack, per se, muito menos contra as pessoas que o compõe – eu os considero colegas e amigos, eu só acho que nós surfamos ondas diferentes e isso me faz achar que eu não agregaria valor ao grupo e vice-versa. Obviamente posso ser convencido do contrário eventualmente =)

The Blocks C extension and GIO asynchronous calls

So, I intended to be completely away from my computer during my vacations, but hey. I have been interested in this new extension Apple added to the C language a little while ago which introduces the equivalent of closures to C. Today I spent a few minutes looking into it and writing a few tests with the help of clang.

Here’s something I came up with, to use a block as the callback for a GIO asynchronous call:

[sourcecode language=”cpp”]
#include <Block.h>
#include <gio/gio.h>

typedef void (^Block)();

static void async_result_cb(GObject* source,
GAsyncResult* res,
gpointer data)
Block block = (Block)data;

int main(int argc, char** argv)

if (argc != 2) {
return 1;

GMainLoop* loop = g_main_loop_new(NULL, TRUE);
GFile* file = g_file_new_for_path(argv[1]);

NULL, async_result_cb, (gpointer) ^ (GAsyncResult* res) {
GError* error = NULL;
GFileInfo* info = g_file_query_info_finish(file, res, &error);

if (error) {
g_error("Failed: %s", error->message);

g_message("Content Type: %s",
g_file_info_get_attribute_string(info, G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE));



return 0;

Pretty neat, don’t you think? To build you need to use clang and have the blocks runtime installed (libblocksruntime-dev in Debian). Here’s the command I use:

$ clang -fblocks -o gio gio.c -lBlocksRuntime `pkg-config --cflags --libs gio-2.0`

“Porque eu aprendi na faculdade que alocar memória é caro”

Mais um exemplo interessante a respeito daquilo que falei num post anterior. Recentemente uma pessoa que começou a trabalhar em um projeto em que eu trabalho há algum tempo me pediu que opinasse a respeito de um patch dele. O patch original dele havia sido revisado por um colega de projeto e além de umas bobagenzinhas de estilo havia uma única preocupação: “por quê você quer fazer essa mudança?” A mudança era bastante simples: evitava que uma variável fosse liberada e realocada em alguns casos específicos.

Nesse projeto uma das coisas que as pessoas menos gostam é de otimizações cegas. Se você faz uma mudança, essa mudança tem chances de introduzir bugs e de aumentar a complexidade do código. Se você vai incorrer nesse risco, é melhor saber que está de fato fazendo alguma diferença. Por isso, otimizações em geral só são bem-vindas se forem acompanhadas de um teste de desempenho que mostra melhoria. Se não melhora nada, pra que mudar? É claro que há excessões à regra e algumas mudanças acabam simplificando o código e são bem-vindas mesmo se o único resultado for não piorar o desempenho.

Quando eu falei que não é legal fazer otimizações cegas ele me disse: “Cega ou não, estou fazendo a mudança porque aprendi na faculdade que alocações são caras, principalmente porque causam chamadas de sistema e por isso devem ser evitadas”. Opa. Alocações de memória de fato envolvem o kernel, mas será que todas as alocações de memória causam chamadas de sistema e a consequente (e cara) troca de contexto para modo kernel?

Fácil testar isso. Se for verdade que cada alocação gera uma chamada de sistema o seguinte programa vai exibir 100 milhões de chamadas de sistema quando o executarmos através do strace:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv)
    int i;
    char* data;

    for (i = 0; i < 100000000; i++)
        data = malloc(10);

    return 0;


fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe62175000
write(1, "START\n", 6START
)                  = 6
brk(0)                                  = 0x1b83000
brk(0x1ba4000)                          = 0x1ba4000
write(1, "END\n", 4END
)                    = 4
exit_group(0)                           = ?

Mas hein? Duas chamadas de sistema entre os dois writes? Pois é. Acontece que o pessoal que escreveu a malloc() já sabe que pedir memória pro kernel é caro e fizeram a libc pré-alocar uma quantidade maior de memória de uma vez e ir entregando pedaços dessa memória conforme a aplicação pede. Isso significa que alocação de memória não é cara? Não. É razoavelmente cara mesmo que não haja troca de contexto, afinal de contas a libc precisa fazer um tanto de trabalho pra saber quanto tem alocado e saber qual o tamanho de cada pedaço de memória que foi alocado para poder liberar depois com free(). Se ao invés de fazer malloc 100 milhões de vezes eu fizer uma só e fizer 100 milhões de memset() o programinha fica 10 vezes mais rápido.

Isso significa que nós devemos evitar qualquer alocação que seja possível evitar? Depende. Pra começo de conversa esse é um teste extremo, não uma carga de trabalho real. Testes são sempre melhores em cargas reais (ou mais parecidas com algo real). Mas principalmente, se for pra piorar muito a legibilidade do código, torná-lo mais complexo, manter memória comprometida por mais tempo que o necessário, é importante que haja um ganho em desempenho para contrabalancear. E esse ganho tem que ser medido, não imaginado =).

A clutter port of WebKit

In case you missed the news on webkit-dev, Collabora has been working on developing a clutter port of WebKit. It shares the build system with EFL, and most of the backend code comes from the GTK+ port. That means networking is handled by soup, drawing by cairo, multimedia by GStreamer, and so on.

If you’d like to give it a try, you can clone the repository from gitorious:

$ git clone git://gitorious.org/webkit-clutter/webkit-clutter.git

Then to build it you use cmake. From inside the source code directory do this:

$ mkdir build
$ cd build
$ cmake .. -DPORT=Clutter -DSHARED_CORE=1 -DBUILD_MX_LIB=1
$ make

The BUILD_MX_LIB option is optional – it will build what we call the “Mx toolkit library” in addition to the vanilla one. Then you can test that the library is built and working by running the programs inside the “Programs” directory. Enjoy!

WebKitGTK+ hackfest 2010!

Last week I attended the WebKitGTK+ 2010 hackfest. It was a great opportunity to meet up with the other developers, discuss some plans for the future, hack away at WebKitGTK+. But, most importantly, play Street Figher 2 =). Thanks to Collabora and Igalia for sponsoring the hackfest, Igalia for hosting and organizing it (well done!), and the GNOME foundation for having sponsored my trip to Coruña!

Unlike last year we didn’t find any big design issues hurting our work (page cache, I’m looking at you!) on new futures. I also didn’t have any huge plans for new API, although we did manage to get some new stuff in there, like the plugins management API Xan created, and the further work done by Dan in soup. This meant, from my point of view the hackfest has been a great oportunity to look at refactorings that we could do to further simplify understanding the code, changing it, and even sharing it =). Besides pushing the debian packaging of the 1.3.x series a bit further.

Coruña was great as always, and I enjoyed going around, eating and hacking there, although I got a cold on the last days which kinda hindered my ability to stare at the screen for too long, some times. Now that I’m at the hot brazilian summer again I’ll hopefully get better soon =)

Cheers \o/

Sponsored by the GNOME Foundation

WebKitGTK+ and the Web Inspector

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

WebKit2 and WebKitGTK+

So you’ve seen people talking about WebKit2, perhaps have seen someone claiming it “drops support for Linux“, and you’ve been wondering what the hell that means for WebKitGTK+. Well, welcome to the preemptive Q&A section with WebKitGTK+ maintainers =D. Let’s first explore some history so we can better understand what exactly is going on.

What exactly is WebKit2?

Currently, when we say “WebKit” we really mean one of the ports that are built on top of WebCore using the WebKit layer. WebCore is the part that does all of the hard Web-related work, WebKit an API layer that exposes WebCore functionality in a coherent way, so that the platform-specific ports can expose a public API layer for their applications to use, which is usually also called “WebKit”. This WebKit layer was designed by Apple to build the Mac, and Windows ports it maintains, and was later released as Free Software so that other ports, such as the GTK+, Qt, EFL ports could be built on top of it, instead of having to do all the heavy lifting from WebCore directly.

Current WebKit model

WebKit2 is nothing more than the second version of that interface, with a whole lot of changes on what you can expect from it, and on how it interacts with WebCore, and the platform-specific API and UI. First of all, the first WebKit was not API stable, and that interface was usually not made public by the various ports – they only exposed their platform-specific APIs. WebKit2 is being designed to provide a stable, cross-platform, C-based, non-blocking public API. This is huge. It will allow cross-platform code to be written without having to consider language, and port differences for basic functionality.

The second big change is the API will be made fully non-blocking. Currently most things you do are asynchronous already, but some of them may be completed in a synchronous ways (like, loading a string into WebKit instead of an URI). This is important for responsiveness, and is also a very important need for what comes next: process splitting.

WebKit2 will bring into WebKit proper the concept of splitting the UI process from the Web process, similar to what Chromium has. It also much more awesome than what Chrome has for a large number of reasons, including, but not limited to:

  1. It’s being contributed directly to the WebKit project, in a cross-platform way that lets ports such as WebKitGTK+ take advantage of it, instead of being shipped directly into Safari, like Google does with Chrome;
  2. The process separation goes bellow the API layer, meaning that all complexity involved in managing the process separation is handled by the library, and hopefully none of it leaks to the application using it; that means that applications like Devhelp and Yelp will be able to take advantage of this without having to make their lives more complicated;
There’s a much better diagram in WebKit2’s wiki page, but here goes a simplified version that demonstrates what I’m talking about:
WebKit2 model

What WebKit2 is not?

WebKit2 is NOT a rewrite of the whole WebKit stack. Webcore will continue mostly unchanged, and all ports currently building on top of it will keep working. It is also not a fork – the code lives in the same tree as the current version of WebKit, which will allow us to progressively move towards using this new, improved layer. WebKit2 is not Apple-only, and it is not dropping Linux support. Initial builds of the code that is being landed will likely show up building on Linux in the near future (specially because us porters are already eager to play with it).

What happens to WebKitGTK+?

In the near future, nothing special. We will continue working towards making it feature-complete, more stable, faster, and rocking on it as always. We will, though, start working out how we can best take advantage of WebKit2 in order to provide an even more awesome library for the G world. What this means is you can expect us to have a library that will provide a nice GTK+ widget, just like we have today, with a GObject-based API, like we have today, but that is built on top of this new WebKit2 infrastructure, taking advantage of the process-splitting, and the bigger focus on not blocking the UI thread. This should give us a platform that is more stable, and faster and more responsive than what we already have today.

The API is bound to change, of course, but the WebKit2 version of WebKitGTK+ will be a separate, parallel-installable library, and we will keep supporting the WebKit1 version while we work on making the new one at least as good as the current one. This is long term we’re talking here. We’ll likely see WebKitGTK+ 1.4, and 1.6 come to life before we are satisfied enough with WebKitGTK+2.

We hope this clears some of the doubts up, and lightens your hearts!

The WebKitGTK+ maintainers.

Designing from the bottom up

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.