Last week PySide was launched, the team was glad to see the project finally go public and receive the community feedback, be it positive, negative or both. Many questions arose, like “Why duplicate efforts?” Well, I can’t say much more than what is already answered on PySide FAQ. For us (the team) the fact is that we had a task to accomplish and must perform it the best we can. That said, allow me to remind you that this is my personal blog and many of the views here written are my very own cherished opinion.

The other question that we’re waiting for, and my personal favorite, was “Why Boost.Python?”. Though one. First of all, Boost.Python eases very much the creation of C++ libraries bindings for Python. How to infer which method signature to call based on the Python arguments passed to the method wrapper? Boost.Python will take care of it. Inheritance? Type conversion (in opposition to type wrapping)? You bet: Boost.Python will take care of all this for you. The feature full Boost.Python gave us a great kick start and at first we progressed very fast. Occasionally some strange bug appeared and took some time to figure out the problem through the jungle of template error messages. Part of the job anyhow, and after that: fast pace again.

At some point somebody checked the size of the produced binary modules. “Hey guys, is that correct?”, “Ah, just strip the file.”, “Still huge.”, “Holy cow…”. Next task: size reduction. Some redesigns reduced a good deal of megabytes, g++ flags were also helpful, but these things weren’t enough. Then a new idea: “Let’s try it with the Intel C++ compiler and see what gives.” It gave binary modules with feasible sizes. Good, but the test just proved that it was possible to achieve the reductions. Besides, there were still other new ideas to try, and the fact that as soon as the project was launched the community would step in and say “I had this size problem with Boost.Python before. Here is how I solved it…”. (Which reminds me how limited, communication wise, a project is in its non-open phase. And don’t point your finger, mister — for every open source project has it’s non-open phase, even in your head!)

Part of the team was growing skeptical about the size reduction problem. Why not to try CPython code generation right now? Well, some say you can’t change the plane’s motor while flying, and this is true. Feature wise we were almost there and the reduction was possible. Also some of us had mixed feelings about CPython. In a past project a comparison was made about writing bindings with different technologies, including CPython, to check for speed, size and the burden imposed on the developer. At the end the guy with CPython had good numbers (not stunningly better than the others, at least for the case that mattered back then), but his personal impression was that he was suffering the Stockholm syndrome: he knew CPython abused him, but he developed a bond with his kidnapper.

Still, almost every one started personal (and voluntary, aka “made at home”) experimentation with different CPython generators (even a ctypes one!), and in the end all the ideas (including the ones from the Boost.Python generator) were merged into a single CPython generator, called Shiboken.


Before going on with this, allow me to explain that Shiboken means absolutely nothing. Not buddhist void, I just mean that the word Shiboken has no meaning attached to it. Except, of course, “generator of CPython based binding code for C/C++ libraries”.

Disclaimer: I don’t know a thing about Japanese language and the above kanjis are just something that I found at wikitionary to match the sounds of Shiboken. Forgive me, Lauro. 🙂

The conspirators’ plan was to develop the alternative generator to a point that could generate PySide bindings that pass all our unit tests, run the apps, etc, thus beign able to replace the Boost.Python front-end. For PySide users, i.e. Python programmers, the replacement would bring no impact, since the API should remain the same. The Shiboken generator is based on the same principles of the Boost.Python one: built using the API Extractor library, how the C++ library should be exported to Python is described on a Type System file, and so on.

Shiboken Generator

The power of Lego-fu!

When Shiboken reached a point that we’d think was good enough to start working with it at work, we presented it to our bosses and the green light was given. The Boost.Python generator will continue as the tool to generate the official PySide bindings, but with the parallel efforts we hope that Shiboken takes its place, the size reduction is achieved, and the Occam’s razor cut off the unnecessary entities.


Occam's razor demands that Boost.Python go

C/C++ Bindings

Another fix that we aim to achieve with Shiboken is to allow non-Qt C++ and C libraries to be wrapped with the generator scheme. The problem with the current Boost.Python generator is that even a non-Qt library wrapped with it will depend on Qt. Of course this is not the best we can do, but the fixing task had low priority since the PySide bindings are the main target of the work. For Shiboken we make it library agnostic from the start, specially because we do not get our chances trying to wrap the whole Qt from start: a test library with all the problems that could arise was made and is the source of all Shiboken unit tests.

Shiboken Features Worth Noting

Abandoning Boost.Python means abandoning some features already provided by it. One that is worth mentioning is the decision of which signature of a method should be called depending on the Python arguments passed on the call. For this to work we have to write a decisor that progressively checks the argument types until the correct signature is found. Just this? Of course not, the binding developer can use the Type System description to remove method signatures, remove/change the type of its arguments, even remove/change/set its default values! The method call decisor must take everything into account.

Overloaded Method

Debugging a multiple signature method call decisor is easier with the "dumpGraph" method.

No Boost.Python also means that would be harder to convert types and containers back and forth between C++ and Python. The template specialization technique was used to solve this one.

template <> struct Converter<bool> {
  static PyObject* toPython(ValueHolder<bool> holder) {
    return PyBool_FromLong(holder.value);
  static bool toCpp(PyObject* pyobj) {
    return pyobj == Py_True;

Why not generating “pyobj == Py_True” directly, you say? The above code scales better, since it will be the same for types that are composed of some primitive types inside containers inside containers, etc. Besides, the compiler could be counted on to inline short methods.

“They have a plan”

Right now Hugo (from PySide fame) started working on generating bare QtCore bindings without QObject and signals, then go to QObject. After that we should solve the signals problem, re-write the pieces of custom code and so on. I think after QtCore is completely done we can make a comparison with the one produced by the Boost.Python generator and see if the whole Shiboken idea can stand to its promise. The best should win for the honor and glory of open source.

We encourage everyone interested in the creation of Python bindings for C++ libraries to test Shiboken, report problems (we now have a component on OpenBossa bugzilla!), and tell us if something is missing for your library to work. Patches are always welcome as usual. 🙂

Shiboken on gitorious:


A few days ago the project that I worked on for sometime finally went public: PySide was launched!

PySide - Python for QtAnd “what is PySide?”, you ask me. It is a binding of the Qt4 framework for the Python language created by INdT and Nokia (Moi, tamperelaiset!) under a LGPL license. My team (not that I’m the owner, “mine” in the sense of “our not including the listener” — I think there is a plural for that in Finnish or Quenya) worked as mad and the launching was smooth: we have a positive reception from the community and the news are popping up everywhere.

And we give not only the fish but also the fishing rod: the binding generator was also made available. But what is the importance of this? Since the news was given, the explanation follows.

But before I continue, pay attention to the little Prince of Persia like bottle on the PySide logo. This nice image is a branding used in projects from the Qt Labs Americas.

The Bindings

The main motivation to start the PySide project was to provide Python bindings of the Qt4 library under a LGPL license, to follow the very own Qt4 LGPL license offer from Nokia. Many possibilities on how this should be done where analysed, and before this sentence start an endless technical discussion I must say that all the options have strengths and weaknesses, but aren’t that much different. In the end it was a mix of right-tool-for-the-job, team’s acquaintance with the technologies involved and personal taste. Just to mention a personal favorite, I really appreciate Smoke. In the end we choose to alter an existing binding generator (more on this later) and use Boost.Python as the middle-man to talk to CPython API. To express this with colored boxes this is PySide right now:

PySide architecture with Boost.Python

The Generator

Writing bindings for a library so massively huge as Qt is a task… no, it’s not a task, it is a punishment. Beign reasonable people as we are, a previous research has been made and we opt to adapt the code from QtScript Generator,which is a fork of the Qt Jambi’s Generator, and both are binding generators for QtScript and Java, respectively. They’re developed by Trolltech (when it was called Trolltech).

The binding generation scheme works like this:

Binding Generator Scheme

The global.h file includes all headers (or at least the desired ones) from the library beign wrapped, and is also used to define (and undefine) preprocessor macros. typesystem.xml files contains descriptions of how the library should be exported to the target language and other semantic information: rejeted classes, renames methods, types to be converted, which methods move object ownership from Python to C++ and the otherway around, and specifies where handwritten code for special cases should be inserted. If there is no need for changes, this XML will be a simple list of classes, enums and functions.

Notice that we not only forked the QtScript Generator, we also converted it from an monolithic application to a library + front-end generator scheme. And here is another picture to show the idea:


Theoretically the projects from where we derived code could be changed to use the API Extractor and share this code base (and bugs, and fixes, and improvements). Nevertheless this will not be that straightforward, since we have made a number of changes to the typesystem format, from simple things like tag renaming (mostly changing “java” to “targetlang”) to more complex things that I’ll not exemplify here. Besides that, one could write front-ends that use API Extractor to generate things other than bindings: class diagrams with GraphViz, statistics, something-that-i-did-not-thought-about.

Now for the not so beauty part. In a perfect world the C++ to Python binding generator could generate bindings for any C++ library, although, in the way it is right now the generator is useful only for Qt based libraries. Shame on us! Anyhow, taking into account that our main target was to create Qt bindings and that a beta version of them was released, I suggest you forgive us. 🙂 Of course that it is in our plans to solve this and make the generator a useful tool for as many people as possible.

To much information for now! For the time beign download, test, report bugs and enjoy. And, if you’re feeling social, go to #pyside channel on FreeNode and subscribe to the mailing list. Everybody is welcome.



Agora sim, chega de trabalhar na moitinha igual contra-regra, o negócio agora é público: PySide foi lançado!

PySide - Python for Qt

Sim! E o que é PySide, você pergunta? São bindings da biblioteca Qt4 para linguagem Python criados pelo INdT e a Nokia (Moi, tamperelaiset!) sob licença LGPL. Minha equipe (não sou dono dela, minha no sentido de “nossa sem incluir o interlocutor”) trabalhou feito louca e o lançamento foi uma beleza: tivemos um retorno positivo da comunidade e as notícias estão aparecendo em toda parte.

E fornecemos não apenas o peixe mas também a vara (na boa): o gerador de bindings também está disponível. Mas qual a importância disso? Dada a notícia vou explicar com calma.

Antes de continuar repare na garrafinha de Prince of Persia no logo do PySide. É a marca usada em projetos do Qt Labs Americas.

Os Bindings

O motivo primário da criação do PySide foi prover bindings Python da Qt4 sob a licença LGPL, para se alinhar com a oferta da Nokia da própria Qt4. Várias possibilidades de como fazer foram analisadas, e antes dessa frase começar uma discussão técnica infinita, todas as opções tinham pontos bons e ruins, mas não tão diferentes assim. A idéia do Smoke foi uma das que mais gostamos e vale uma menção. No fim optamos por alterar um gerador de bindings existente (mais sobre isso abaixo) e usar o Boost.Python para fazer meio-campo com a API CPython. Trocando em diagramas coloridos esse é o PySide:

PySide architecture with Boost.Python

O Gerador

Escrever bindings pra uma biblioteca tão massivamente grande quanto Qt é uma tarefa… não, não é uma tarefa, é uma punição. Pessoas de bom senso que somos demos uma pesquisada por aí e optamos por adaptar o código do QtScript Generator, que por sua vez é um fork do Qt Jambi Generator, e ambos são geradores de bindings QtScript e Java, respectivamente, desenvolvidos pela Trolltech (quando ela se chamava Trolltech).

O esquema de geração de bindings funciona assim:

Binding Generator Scheme

O arquivo global.h inclui todos os headers (pelo menos os desejados) da biblioteca sendo processada, e também define e desdefine flags do preprocessador. Arquivos typesystem.xml são descrições de como a biblioteca deve ser exportada para a linguagem alvo: classes rejeitadas, métodos renomeados, tipos convertidos e, muito importante, códigos escritos à mão para casos especiais e onde eles devem ser inseridos. Se não houver necessidade de alterações esse xml será apenas uma simples lista de classes, enums e funções.

Notem que não apenas forkamos o QtScript Generator, mas a convertemos de uma aplicação monolítica num esquema lib (que chamamos de API Extractor) + front-end gerador. E mais uma figura pra explicar a idéia:

BoostPythonGenerator Teoricamente os projetos dos quais derivamos código poderiam ser alterados para usar o API Extractor e compartilhar essa base de código (e bugs, e fixes, e melhorias). Além disso, o sujeito pode escrever front-ends que gerem outras coisas que não código: grafos de relacionamento entre as classes, estatísticas, algo-que-eu-não-pensei.

Agora a parte não tão bela. Num mundo perfeito o gerador de bindings C++ para Python geraria bindings de qualquer biblioteca C++ para Python, contudo da forma que se encontra agora o gerador serve apenas para bibliotecas baseadas em Qt. Grande vergonha! Considerando que o foco era criar o bindings Qt e os lançamos em versão beta, sugiro nos perdoar. 🙂 Claro que está nos planos resolver isso e tornar o gerador uma ferramente genérica e útil para mais pessoas.

Informação demais! Por hora, baixem, testem, relatem bugs e aproveitem. E se estiverem se sentindo sociais entrem no canal #pyside no FreeNode e assinem a lista de discussão.


Maemo SDK Appliance, release 0.6 “Be kind.”

New vm appliance everybody, the last one was redone from scratch because of some problems with Open VM Tools, and I managed to miss other things too, like the hildonmm development packages. ><

This one, even still made by a humble human, should be (almost (i hope)) bug free. As usual updates to the packages included, check the changelog:

  • The latest PyMaemo.
  • Eclipse with CDT 4.0.2, PyDev 1.3.14 and ESbox 1.3.6 plugins.
  • Using Open VM Tools ver. 2008.02.13-77928.
  • Using kernel for virtualization.
  • Scripts to automate image creation.
  • EFL (ecore, evas, etc. and python-evas) installed from extras repository (instead from CVS source).
  • Nokia Binaries installers fixed.
  • Vala not included in this version.

Download in the website.

Menus de Torta com Python e Cairo

Um tempinho atrás experimentei fazer uma interface do tipo pie menu, aqueles menus circulares, usando Python e Cairo. A idéia era usar num tipo de arena de combate usando marcadores para representar os lutadores, com ações escolhidas em menus de contexto circulares.

Melhor um screencast que palavras:

Veja o código aqui. Os arquivos são (execute este), e
Ou use o subversion:

svn checkout piemenu

Funciona assim: a classe Arena é um widget que pode conter objetos da classe Token (os marcadores representando personagens), estes por sua vez contém um objeto da classe PieMenu, que é composto por vários itens.

Em código:

arena = Arena()

piemenu = PieMenu()
piemenu.add_item('icon1.png', do_callback, 2) # (icon, callback function, callback params...)
piemenu.add_item('icon2.png', do_callback)

token = Token((200, 100), 'token-icon.png', piemenu) # (position, icon, menu)


Então você adiciona a Arena num container qualquer e está pronto.

ESBox Rápido e Fácil

Não é um curso, nem um livro milagroso, apenas um scriptzinho bash. E pra falar a verdade, o “rápido” no título depende muito da sua conexão.

O ESBox é um plugin pro Eclipse que ajuda um bocado a programar pra plataforma Maemo. Ele incluin suporte a C, C++ (><) e Python. Como ele depende de versões específicas dos plugins CDT e PyDev, e do próprio Eclipse, pode se tornar chato de instalar, pra mim mais chato ainda, porque tenho de fazer isso de tempos em tempos pro Maemo SDK VMware Appliance. Se algo fica de fora tenho de andar na prancha. Não mais! Esse script aqui [] instala tudo, do Eclipse pra cima até chegar no ESBox. Só não instala o Scratchbox e o Maemo, esses ficam por sua conta.

Resta apenas configurar o interpretador Python a ser utilizado pelo PyDev. Siga estas instruções.  Não consegui encontrar o arquivo onde o Eclipse (e o PyDev) guarda  as configurações. Chave GConf também não foi achada.

<dearlazyweb>Se alguém souber onde fica guardada a informação de qual interpretador usar, me avise.</dearlazyweb>

Ah, quem já conhecia o Projeto ESBox vale uma outra olhada no site deles que tá novinho em folha.

TagGen 0.3.1: Instalador para Windows

Aproveitei que fui obrigado a usar Windows hoje aqui na federal e resolvi fazer o bendito instalador pra versão 0.3.1 do TagGen.

Dois screenshots:

No screenshot acima, o desenho do humanóide representa a altura e peso de forma visual. Mais acima note a representação da idade do personagem acompanhada de informações históricas do mundo de Tagmar. Perceba também os botões com ícones de dado vermelho, eles provocam o sorteio aleatório dos valores de altura, idade e peso.

Este é o diálogo de escolha da região de origem do personagem. Claramente ripado do TagMap. Você irá notar que ele precisa melhorar um bocado.

Faça o download do instalador para Windows, e esteja avisado que ainda é software Alfa. Relatos de bugs, comentários e sugestões são bem-vindos.

TagGen, Gerador de Personagens para Tagmar 2 (ponto 2)

Há muito tempo atrás foi criado o primeiro RPG nacional, chamado Tagmar, e ele gerou uma horda de nerds matadores de orcos de fim de semana. Como já falei sobre no post do TagMap, vou pular as apresentações, mas digo que uma coisa que sempre fez falta em Tagmar foi uma Tabela (ou Escudo) de Mestre, uma que não fez falta, mas só porque naquela época não tinha dessas coisas, foi um gerador de personagens, e foi isso que resolvi fazer pro Tagmar 2 (ponto 2).

Antes de começar a falar sobre a aplicação, aviso que a versão que estou disponibilizando é Alfa, ou seja, não é Beta, ou seja, ainda não serve para ser usada no dia a dia, se prestando mais a uma avaliação inicial por parte de intrépidos testadores, curiosos e possíveis colaboradores. Agora enfio um screenshot:

Tela principal de TagGen

Batizei a criança com o criativo nome de TagGen (Tag de Tagmar e Gen de gerador :P), e a idéia é não só facilitar a criação dos personagens pra começar logo a bendita partida, mas também guardar dados da história e evolução do personagem, mais ainda: também deve ser possível “exportar” personagens e enviá-los para outros jogadores, imprimir a ficha, etc (veja a página do Roadmap para mais “etc”). Uma coisa que gostaria de fazer é um processo de criação alternativo, no estilo daqueles quizzes “Quem é você em…”, que são um tipo de teste de personalidade que indicam quem você é num determinado contexto (livro, filme, anime, e por aí vai). Daí o sujeito apenas com a idéia do tipo de personagem que quer interpretar pode pular toda a parte numérica e de escolha de habilidades, magias, equipamento, etc.

Novamente sobre facilidade, note que no screenshot acima o polígono representa os atributos do personagem e o jogador os define arrastando as bolinhas com o mouse. Essa parte foi um pouco inspirada em Ragnarök Online, e é particularmente útil pois a distribuição de pontos de atributos inclui uns cálculos cabulosos (mas não a ponto de serem assustadores), e creio que a parte mecânica-matemática fica bem melhor com a máquina.

Criando um novo personagem

A tela acima mostra o começo da criação do personagem: raça e profissão são escolhidos primeiro, pois essa decisão restringe todas as outras possibilidades. Determinadas raças não combinam com algumas profissões, e para mostrar isso de forma natural, as profissões proibidas desaparecem da lista ao escolher uma raça que possua restrições. Essa e outras características você pode ver no screencast que deixei lá no Google Video, ou na versão de melhor definição no formato Ogg/Theora.


Bom mesmo é instalar o TagGen, na seção de downloads do site temos:

Como aconteceu no primeiro release do TagMap, não tive tempo de fazer um instalador pro Windows, como essa versão é muito Alfa, não entro em detalhes, deixando por conta de quem for tentar executar, adiantando que você precisará de Python, GTK+ e PyGTK, nessa ordem, mas eu recomendo fortemente o PyGTK All-in-One Installer.

Técnica da Coisa

Como se viu acima PyGTK foi usado para interface; para os dados de raças, magias e habilidades, foi usado o banco de dados SQLite, que já vem embutido em Python, e é uma das coisas mais porretas que já se viu na Fenda do Biquíni; o widget de definição de atributos foi feito usando Cairo (que faz parte do GTK+), mas isso eu já expliquei num post anterior.

Dificuldades e Como Ajudar

Qualquer problema, idéia ou sugestão registrem uma ocorrência lá na seção Issues, lá na página do projeto, que é destinada pra questões envolvendo o software. É bem fácil preencher um novo item de problema/sugestão, mas caso se sinta intimidado, pode mandar emails ou comentários. Infelizmente estou com pouco tempo livre ultimamente, e é aí que retorno pode ser de grande valia pois vai ajudar a me orientar nos pequenos espaços de tempo livre que aparecerem.

Uma coisa que atrapalhava muito no TagMap era a coleta de dados e sua subseqüente inserção. Na época não convoquei ninguém pra ajudar, mas também a coisa ficou parada, embora a falta de tempo e o fato da aplicação ser mais uma curiosidade do que uma utilidade falaram mais alto.

TagGen sofre de uma dificultade parecida, pois inserir as magias, habilidades e itens no banco da aplicação podem demandar um tempo razoável. Se você quiser ajudar com a inserção de dados (e outras coisas), deixei uma página explicativa no site: ComoAjudar.

Formatos de Arquivo Amigáveis

Uma coisa que tentei em TagMap foi fazer um script para extrair os dados das localizações direto do arquivo do Livro de Ambientação, pego do fórum (acho que era um fórum, faz um tempo já) de Tagmar 2. O arquivo era um .doc do Word, que é um formato fechado, por isso abri no e salvei como .odt, formato aberto que por dentro é XML, daí fiz algo como o descrito num post anterior, me baseando na estrutura de títulos (“Título 1”, “Título 2”, etc) consegui resultados razoáveis. Às vezes, porém, a pessoa (ou pessoas) que editou o arquivo usava texto comum para títulos, mudando apenas o tamanho da fonte, que é diferente de um título “real” apesar da semelhança, e isso quebrava a estrutura do documento e melava o script. Mesmo assim vou tentar novamente essa abordagem, mas certamente vou precisar de revisores. 😉

Se você estiver lendo e for contribuidor direto do projeto Tagmar 2 (me considero contribuidor esporádico com 2 graus de indireção), eu sugeriria o uso do (ou aqui no Brasil) e do formato .odt para os livros de Tagmar 2, pois estaria mais de acordo com a natureza de liberdade que em primeiro lugar possibilitou a existência do projeto. Perceba que não é só pela questão filosófica, que é bem forte, mas tenha em mente, como deixei claro no parágrafo anterior, coisas abertas (formatos, códigos) são mais amigáveis para quem quer inventar algo novo. Se alinhando melhor com tecnologias de software livre e padrões abertos o projeto Tagmar 2 pode atrair a atenção de desenvolvedores, podendo surgir coisas como, um exemplo que me ocorre agora, um sistema web de edição de coleções (magias, itens, criaturas), para posterior geração de arquivos que necessitariam de poucas alterações de diagramação para lançamento. Esses dados organizados podem servir para alimentar outras idéias e por aí vai. Contudo, sendo realista, não estou sugerindo que abandonem um sistema de produção que está funcionando, e muito bem, haja vista a qualidade do material. Proponho somente que algumas melhorias são possíveis, digamos colocar os arquivos “fonte”, os documentos, sob um controle de versão, e/ou ter um sistema de controle de bugs para melhor rastrear defeitos nos livros. Verdade que não freqüento muito os fórums do projeto e posso estar chovendo no molhado, mas não faz mal deixar o recado.

Novamente quero parabenizar o povo do projeto Tagmar 2, valendo mencionar o pessoal da arte, que manteve (na minha opinião) o clima das ilustrações do primeiro Tagmar; e também o Marcelo Rodrigues que tem guiado muito bem esse barco.

Nota para mim mesmo: lembre de colocar uma nota sobre a licença do conteúdo usado no TagGen, conforme esse post.

Maemo SDK Appliance, release 0.4 “Not So Fat”

Finally the new version of the appliance, and it is “Not So Fat” as we expected, since it is loaded of good stuff. See the Release Notes:

This release is loaded with a lot of goodies: Maemo 4.0 (Chinook) final and Maemo 3.2 (Bora) with Nokia Binaries Installer, PyMaemo packages, Vala compiler and its Hildon bindings for Chinook, Maemomm libraries, EVAS (Bora and Chinook, but i386 only), qemu-arm-eabi used as default cpu transparency method, Eclipse with ESbox plugin, and Firefox has now a lot of bookmarks for reference material. There are code samples for all the libraries and development packages cited above.

Checkout the ChangeLog entry:

* Scratchbox installed from official Debian Repository.
* Maemo 4.0 (Chinook) release.
* Maemo 3.2 (Bora) (the last release was using 3.1)
* Use the qemu-arm-eabi as default cputransp method
* Nokia Binaries Installer for Chinook and Bora
* Added a lot of bookmarks in Firefox for reference material.
* Maemomm (C++ bindings) added, with
code samples.
* EVAS libraries added to Bora and Chinook i386 targets, along with code samples.
* Eclipse with CDT 4.0.1 and ESbox 1.2.0 plugins.

Watch a screencast on Google Video (YouTube doesn’t like Ogg/Theora, and I’m feeling very lazy to bother converting) with a sample session of using Eclipse with the ESbox plugin to create a Maemo project. For a higher resolution version, download the ogg.)

Download torrent from PirateBay (prefer this way; yarrr!):

Or direct download in two parts:

You will need 7zip to unpack the files.

Update: direct download link fixed. Thanks tabrez. 🙂