Libertexto: integrating Evince into Firefox

These months I’ve been collaborating in Libertexto development. Libertexto, a project coordinated by Rafael Ibáñez, will be a Firefox extension whose goal is to allow the user to do some text comprehension tasks (highlight, add annotations and create bookmarks) and concept mapping tasks (manage a tree of “lexias” or units with semantic content) on HTML and PDF documents.


So far, I’ve mainly been involved in the task of integrating Evince into Firefox. The goal was not only to provide support for PDF document viewing, but also to adapt Evince to manage the communication with the Firefox extension and to provide the required functionalities and GUI interaction. The fact that Libertexto has to work both in Linux (Ubuntu Jaunty) and Windows made the task more challenging and had an important influence in the design decissions.


The plugin

The main idea was to write a plugin registered to visualize documents having the “application/pdf” mime type, using Evince for that, and interact with the XUL/Javascript code to coordinate everything. The npsimple (check my npsimple backup link) example was very valuable to learn how to code a multiplatform basic plugin implementing the Netscape Plugin API (NPAPI). These first testings (with the help of Dependency walker) showed me that the plugin code would only load if compiled with the same compiler used to build Firefox. That means forgetting Cygwin, MinGW32 and other Windows platform free stuff and compile using Visual C++, getting the headers from the Mozilla SDK.

Communications: first try

Once I had a plugin that did nothing, I looked for ways to communicate it with Firefox. I tried some XPCOM examples and debug tools without much luck, so I finally decide to use alternative ways of communication when I needed to.

Compiler restrictions

At this point I focused in compiling Evince for Windows. I chose Evince 2.28.0 because it had been already compiled for Windows by Hib Eris. I found him in the #evince IRC channel and he pointed me to the Ubuntu PPA he had used to cross compile for Windows using MinGW32. He also confirmed to me that mixing MinGW32 compiled apps with MSVC compiled apps is a problem because MinGW32 compilations are dependant on msvcrt.dll, while recent MSVC compilations depend on msvcrt80.dll or msvcrt90.dll. That explains why I couldn’t compile the plugin with the MinGW32 toolchain from Windows. Forget also about converting Evince itself into a plugin (implementing NPAPI), because it won’t load. There’s currently no easy solution, but to compile everything with MSVC (not tried before) or keep applications split.

Embedding the window

After having compiled Evince and all its dependencies for both operating systems I modified the plugin to start Evince each time a new document was loaded. Next step was to find a way to embed Evince in Firefox, because having it as an independent window was not an option. The plugin was given a window ID (XID in X11, HWND in Windows), so I modified Evince to receive it as an extra parameter and use gtk_window_reparent() to “hijack” the window that Firefox provided. Of course, using Mozplugger is much easier, but it’s not supported in Windows, so I had to do it by hand. After some tweaking and having to disable DBUS support to get exactly one process per document (in Linux), it worked in both systems. In Windows I ended up with refresh and focus problems, but I didn’t go further.

Communications: second try

At this point, the key was to have a reliable communication system between Evince and the plugin. DBUS would have been good for Linux, but would bring too much problems in Windows (everything should be installed or work from the Firefox extension bundle and I’d need a way to use DBUS from javascript). Standard IPC methods (eg: shared memory) would be a problem too, because I hadn’t managed to successfully develop XPCOM components that could access low level C functions to use that IPC methods. However, there’s one thing that always work: plain old HTTP requests. They are supported in the Firefox side using XMLHttpRequest and in the Evince side using libsoup-2.4. I had experience using libsoup in Meiga, so it wasn’t difficult for me to set up a bidirectional realtime communication middleware using the AJAX paradigm.

The initial port handshake is a bit tricky, though. Remember that there’s no way for the Firefox extension, the plugin and Evince to talk to each other before this handshake. The process is as follows:

  1. The user opens a URL containing a PDF, so the PDF plugin is invoked. If the plugin is in Linux and detects that libertexto hasn’t been installed in /usr/local/libertexto-0.0.5 yet, it triggers the install script and waits until the process is completed. Then continues.
  2. Using dll/so API calls on the first load, the plugin gets the path where nplibertexto.dll/.so is installed (eg: /home/user/.mozilla/firefox/ky712h81.default/extensions/ From that path it gets the extension path ( and builds the xid directory path (
  3. The plugin gets the URL and the downloaded file name through NPAPI. It then launches Evince (fixed location in Linux, variable location under the extension dir in Windows) with the following parameters: evince --xid 0x6800001 --libertexto-path /home/user/.mozilla/firefox/ky712h81.default/extensions/ /home/user/local_links.pdf.
  4. Evince opens the file, hijacks the window with handler 0x6800001 and starts a web server on a random port of which will wait for incoming connections. Then the port number is written to a file named 0x6800001 in the xid directory.
  5. The plugin has been waiting up to 5 seconds and monitoring the xid directory for new files. When it finds a new one, reads it and inserts the (xid, process id, MD5 sum of the URL, port) into a children array for further use. Each time the children array changes, the file is regenerated. That file has the URL MD5 sum and port, one line per document.
  6. The file is available as resource://libertexto-docs/ to the Firefox extension and it’s monitored each 5 seconds using XMLHttpRequest (it can also read local files). That way, the extension keeps a table of open documents and their ports.
  7. Each time the extension detects a new entry in the table, it connects to the port using XMLHttpRequest on a special “receive” URL (eg: and reads and attends any pending messages that Evince would like to communicate. If there are no more messages, just keeps waiting for one to come. When one comes, the network dispatcher in the Libertexto extension attends it, closes the connection and restarts it to wait again. Evince code just enqueues outgoing messages and writes them when the extension (re)opens the connection.
  8. If it’s the extension who wants to send a message to Evince, a request is made to a “send” url (eg: There’s also another network dispatcher in Evince that processes incoming messages and calls the corresponding function of EvApplication.
  9. When the document is closed, the plugin code is informed by NPAPI and just ensures that Evince is killed, the 0x6800001 xid file is removed and libertexto-docs is rebuilt.


It was time to polish a little bit the building and packaging environment. Different binary sets for different platforms can be provided using the platform directory in the Firefox extension package. In Windows, there’s no problem in relocating a GNOME app where you want, as there’s specific code to locate the data and config dirs, but in Linux it has to be installed in a fixed location, so I prepared a very basic installation script for that platform to be executed by the plugin the first time that the user opens a document.


With the infrastructure ready, I started to hack on Evince and implement the required functionalities (and the related middleware messages in both sides):

  • Get the text directly selected by the user
  • Scroll to a specified position of a specified page in a document
  • Highlight some (preselected) text with the specified color
  • Set an “start of selection” internal mark
  • Set an “end of selection” internal mark and then select the text between the start and the end of selection
  • Show the “create new item” option in the context menu and pass that command to the Firefox extension
  • Overimpress an annotation with some arbitrary text
  • Overimpress some icons that would trigger some commands on the current items

For some of them, specially those related to text highlighting and annotations, the advice from Carlos García Campos was very helpful. Shell, view, document and backend layers, the pixbuf cache, the jobs system… Evince is a big project and I needed some time to get used and understand it, but it has a lot of things to learn. I enjoyed very much this development stage. 🙂

When all the PDF side functionalities were completed, I removed all the unneeded GUI options from Evince and adapted the Libertexto extension panel to produce and handle the required middleware messages needed to manage the user interaction.


The result

Although the project still lacks part of the control and HTML modules functionalities, I got Evince integration working in this nice prototype.

You can download it as: libertexto.xpi (UPDATE 3/3/2011: you might prefer to download the final Libertexto 1.0 version). Please note that this file will probably evolve, being overwritten with newer versions.

Until the whole project gets released, a shapshot of the Evince branch code is published in Gitorious for you to have a look.

Meiga 0.3.3 released

The two main features of this new 0.3.3 release of Meiga are the new redirection support for FON routers (Fonera v1) and memory optimizations for large files, so serving a video file of 1GB won’t eat up all your memory.

Apart from that, some bugs have been solved, the autotools config has been updated (thanks to Javier Jardón), a startup notification has been added (thanks to Rajeesh K Nambiar) and the file size is now passed to the browser, so you’re going to have now a decent progress bar.

As always, you can download it from

Shishen Sho compiled for N900

I’ve recalled about my old Shishen Sho game, originally developed for N810 (Maemo4) and I was wondering if it would compile for N900 (Maemo5). Well, after some minor corrections to make it work in a more recent version of Vala, it compiled. You can downloaded it here:

Disclaimer: It’s compiled “as is”, with no adaption for sliding menus, no new hardware keys and no new fancy features. It just works and will let you have a good time while waiting for the bus.

Meiga 0.3.2 released

This new release doesn’t use GtkBuilder anymore, so the GUI problems caused by incompatibilities between GtkBuilder versions shouldn’t be noticed now.

Files are now iterated instead of being mapped into memory. This makes Meiga a little bit slower but allows execution on low memory machines, as suggested by Steven.

Meiga now also works in Karmic. Just use the Jaunty packages and they will work fine. You can get it from

Meiga 0.3.1 (Halloween edition) released

This weekend I’ve taken advantage of our hackfest sessions at Igalia winter summit and have prepared a new “Halloween” version of Meiga.

The new version solves the bug pointed by xvi82 and ensures that Meiga compiles properly on Ubuntu Karmic (but no Karmic packages are provided yet). In addition, it has improved HTML headers to show a page title and set the proper character encoding. It also has a pending/total transfer counter, so you will know when you can safely exit Meiga without breaking any download.

Meiga can be downloaded from

Meiga 0.3.0 released

After some inactivity time, I’ve started to devote time to Meiga again and developed a set of new cool features, apart of solving some bugs. The result is this new 0.3.0 release.

The most significant new feature is the support for multiple forwarding backends. Now the user can choose not only UPnP, as before, but also SSH forwarding or no forwarding at all (direct connection). What the new SSH forwarding backend does is to connect to a central SSH server and forward the Meiga serving port on it. This way, all the users in the remote SSH server or having direct connection to it, can access to the forwarded port. This connectivity for users having direct visibility of the server is only possible if it’s allowed by the SSH server configuration, though.

The second new feature is the addition of “Share on Meiga…” context menus for Nautilus and Konqueror. That way you don’t have to bother about finding the right folder path in the file selector. For improved security, this context menu will only work if Meiga is already running. No share will ever be served without the user noticing it by seeing the Meiga icon shown in the system tray.

The rest of the changes are minor fixes or collateral changes needed to implement the main ones.

I hope you to enjoy this new version. As always, it’s available for download from:

Guadec 2009 conclusions

This has been a very intense week at Gran Canaria Desktop Summit. I’m very glad about the good reception that Meiga talk had among the Gadec-ES public. Now it’s time for taking advantage of all this work and update the Meiga website with the slides prepared for the talk. I’m sure that anyone wanting to contribute or to understand the project will find valuable information on them.

But not everything has been about explaining our work. I’ve learnt a lot of new things and found new ideas to improve Meiga in the future. I’m not going to talk here about the rest of the talks given by Igalia people. You can read about that on the planet. I prefer to focus on some of the other most interesting talks I’ve attended to:

  • Profiling and Optimizing D-Bus APIs (Will Thompson): Will showcased a graphical profiling tool that shows that D-BUS can be a slow protocol when there is a high amount of calls. One alternative to speed up things is to expose methods to do vectorized calls, performing multiple queries and getting multiple results at once, instead of doing N consecutive calls.
  • Sipping Mojitos and thinking RESTful thoughts (Rob Bradford): Rob spoke about Mojito, an interesting library to access remote REST web services in a convenient way.
  • I can has aliens too? Client side windows in Gtk+ (Alexander Larsson): Alex and his workgroup are making the effort to collapse some X-Window windows into a single big one managed by the client. This reduces flicker and has interesting applications for offscreen rendering.
  • Thinking Outside The Box (Bringing the Network back into GNOME) (John Palmieri): Apart from being a good guitar player, John reflected about some interesting ways for the desktop apps to interact with online services. It’d been nice to integrate the Meiga ideas of “offering directly from the desktop” instead of relying on central services, as he exposed.
  • Vala: Compiler for the GObject type system (Jürg Billeter): The Vala author showed the language I’m in love with. Apart from the already known features, I could see the new asynchronous programming features, which implement coroutines in some way. This concept is a very interesting tool to do clean asynchronous programming and could solve one of the problems I found in Meiga when coding a serie of asynchronous action. My alternative was to code a programmable step interpreter.
  • The Hynerian Empire and beyond (Zeeshan Ali): Zeeshan showed us the features of Rygel, a UPnP media server for Gnome.
  • Let’s make GNOME a collaborative desktop (Guillaume Desmottes): People is using Telepathy (XMPP) to exchange not only messages, video and audio, but also files and using the framework for other kind of communication/sharing uses between applications.
  • Personal Media Networks with Coherence and Telepathy D-Tubes (Philippe Normand): This guy demonstrated Coherence, a framework that is able to link two UPnP networks (eg: two homes) by using one of the UPnP devices in each network as a proxy. This proxy would forward the UPnP messages encapsulating them into DBUS calls and transmitting them over the Internet using D-Tubes, a networked implementation of DBUS. This D-Tubes technology also appeared in other talks and seems to be very interesting.
  • How to play libnice-ly with your NAT (Youness Alaoui): This guy explained how libnice uses NAT punching to make NAT traversal possible for UDP packets. They are currently trying to make it work for TCP also, which would be of immediate application on Meiga. Anyway, in that talk I knew about the existence of TURN servers that play the role of a central communication point as a last resort when direct visibility isn’t available between the peers.