The time has come when The Document Foundation will elect a new Board of Directors. As you might already know, there are many good candidates. And since I clearly think I am the best of them, I am writing this to ask you to vote for me. Some of you might know me a bit already, but it is never bad to present myself.

My name is Fridrich Štrba, national of Switzerland and Slovakia, happily married with Susan since more then 12 years and father of 3 wonderful children: Patrick (9), Miriam (6) and Nathanael (3).

My story with LibreOffice started around 2004, with its predecessor, OpenOffice.org. I was just trying to contribute to libwpd which is the horse-power of our WordPerfect import and the OpenOffice.org integration was an interesting thing to contribute to. And since then, my love story with our project went through different stages, but we are still together and sometimes even happy.

I have been mentoring Google Summer of Code students since 2006 and recently I was co-responsible for several import filters for reverse-engineered formats (i.e. Visio, CorelDraw, MS Publisher). I can frankly say that my development and marketing work around the filters are a huge part of the reason why LibreOffice is called the "Swiss army knife of file-formats". We managed quite recently to bootstrap a vibrant community of filter-writers and the the amount of supported file-formats will only grow.

Between 2007 and 2013, I was highly blessed to be working on LO as my day-job, employed by Novell, then SUSE. Since September 2013, I am again a volunteer as many of you. This new-acquired independence is an advantage. I have no monetary interests of any kind in LibreOffice and, if elected, I will take decisions only and only considering the good of the project as such.

The advantage of my election would be that I am part of various native language communities. I speak several languages and can understand the aspirations of the corresponding communities. Besides that, I was part of the Membership Committee from 2010 and the last year, I was its Chairman. In this quality, I was able to push forward my vision of diverse and open and inclusive community that goes beyond personal sympathies or aversions. And this is the vision I desire to pursue if you give me your trust.

And since it is written "You don't have because you don't ask", with this message I ask you to cast your vote for me.

As many who follow the LibreOffice mailing lists know, soon we will have the elections for the Bord of Directors again. Without doubt, there will be a lot of good candidates and the choice will be difficult. Different competencies, personalities, sensibilities. As many parameters as there could ever be. Nonetheless, there is one parameter that was eliminated from before the first election: the corporate pressure.

From the very beginning of The Document Foundation, the Steering Committee and the initial Membership Committee knew that while corporations can contribute a lot to open source, they can also in some moments try to use the community bodies for their own interest. That is the reason that all elected bodies of The Document Foundation have the 30 per cent rule, where no more then 30 per cent of any body can have the same affiliation. In the same spirit, the election system was designed the way that it is technically impossible for anybody to know how a given member voted. From the experience with the "old good times" of OpenOffice.org, it was obvious that corporate influence can do a lot of harm and skew the elections in a considerable way. And even if the rule of 30 per cent is in place, it might be hard for a election officer or for a MC member to stand strong before a corporate pressure. And this was the reason why we chose a design that makes it impossible even for the election officer to know whom you voted for. This information is known only to you.

Long time not see, dear friends. But that does not mean that there is nothing to speak about. So, hence a new blog post for those that were wondering what was happenning in the reverse-straight engineering partnership.

After the moments in August and September, where I transitioned from working on LibreOffice to working on SuSE Linux Enterprise and after some breathing pause to give to the Cesar (or also known as family) what is belonging to Cesar, the activity on LibreOffice related stuff restarted in October. Just this time, during nights, weekends and other free time.

Sample Keynote presentation in LibreOffice 4.2

It is with a huge pleasure that I realized that we start to have a vibrant developer community around the libwpd/libwpg family, as well as around Valek&aposs reverse-engineering framework. SUSE Hackweek 10 helped me to produce an initial importer for Freehand file-format. Close to that, David Tardon of RedHat fame added a library to parse Keynote files and a library to convert different e-book file-formats. Laurent Alonso works like a bee on importing Microsoft Works spreadsheets (*.wks). Many exciting things in the pipeline, as you can see.

Wireframe of shapes from a sample Freehand drawing in LibreOffice 4.2

With the extension to presentations and spreadsheets, we decided that the time has come to simply break the super-stable libwpd/libwpg API and profit to make it even more future-proof and in the same token solve some of the API issues that were preventing us from importing correctly several features; most notable of which the Visio connectors.

librevenge

We decided to diminish drastically dupplication of code and we extracted from libwpd, libwpg and from libetonyek the API classes along with the used types. We created a new library, librevenge where we also added as sub-libraries the (structured) stream implementations that used to be in libwpd-stream, as well as several classes that the libraries used to copy and paste between them. The structured stream implementations support now both OLE2 and Zip containers and the relevant libraries assume this. That means that we will have to eventually extend the WPXSvStream implementation in LibreOffice&aposs "writerperfect" module to cater for Zip too.

A new sub-library, librevenge-generators has the simple implementations of the interface classes that we use to convert documents into html, text, or that we use to see the raw API calls for the purpose of regression testing. The exception is the RVNGSVGDrawingGenerator class. In the current stable branches, all of the libraries that convert graphics file-formats contain an SVG generator and they rely on its presence in several cases for things like fills with vector graphics. This class is thus not part of the librevenge-generators library, but of the base librevenge, which is a hard dependency of all of the converter libraries.

RVNGPropertyList

The base type for passing information using the API callbacks is RVNGPropertyList, which was born from libwpd&aposs WPXPropertyList. We modified the design of this class the way that each atrribute can have as a value either a simple property or an array of RVNGPropertyList element. This allows us to do more or less all that JSON is able to do. The API classes are even more flexible and future-proof, since extending the information passed in the different callbacks will not modify function signatures.

Quality improvement

Although the relevant libraries were quite extensively regression-tested in the past, the new librevenge extends the coverage of unit tests. We hope that this helps us to keep under control the basic functionalities without having to use the heavy regression tests on each commit.

Other effort is to avoid to copy in the API calls huge data structures. This effort will result in some performance improvements especially if a document contains a lot of shapes that are filled by different bitmap fills.

When will it be ready?

When it is ready! But seriously, we are trying to take our time and get the APIs right. Like this we intend to prevent gratuitous breakages of binary compatibility in the future. So, it will not be in LibreOffice 4.2 for sure.

If this is interesting for you, please drop by at #libreoffice-dev channel at irc.freenode.net in order to meet us. We cannot promise you that you will become rich, but we can guarantee you fame and eternal gratitude

Last week-end, Mozilla held its summit in 3 locations: Santa Clara, Toronto and Brussels. The summit is where contributors paid (employees) or not (volunteers) meet and discuss the future of Mozilla and how we are gonna help shape the web. We call them (ourselves) Mozillians.

I attended in Brussels and it was for me the occasion to meet fellow Mozillians for the first in face to face, and to meet other I had never interacted with. I'm reaching my two years as a Mozillian (and paid contributor) and I see a huge value in this. I found that we have a very friendly and vibrant community, spread across the globe, people passionate about the web, passionate about the users and the future of the web, from developers, designers, artists, translators to evangelist, marketing and administrative support. The full spectrum was represented.

I can't wait to attend the next Mozilla summit, in the mean time I'll attend the Gnome Summit that is being held tomorrow in the city I call home: Montréal.

Also I need to go through the 1900 pictures I took during the event. In the mean time you can watch that set on Flickr that contain the stuff I posted on Instagram almost immediately, as well that the Flickr group Mozilla Summit 2013 I created to pool the pictures from other users (feel free to add yours if you haven't already).

QR Code by lydia_shiningbrightly, on Flickr

This week I am at the Toronto Mozilla office. With Mike and Alan we were discussing information entropy and backups and devised the craziness of doing a hard drive backup onto paper, using QR Codes.

Alan and Mike did the math.

For one TB, it would take 44 trees, and at 20 pages per minute, it would take 123 days to print the 3.6 millions letter-size single sided pages, at 300dpi, in large-size, using the highest-redundancy QR codes.

Now you know how much information we create and how much it would take to make it last longer than the electronic device it is stored on.

Just a service announcement for those that might have around still SXW files generated from WordPerfect documents by the wpd2sxw tool version 0.6.x or earlier (years 2004 and before). Those files used to open fine in early OpenOffice.org versions, but they miss a crucial element. That is the reason why LibreOffice, the OpenOffice.org modern successor, will refuse them. Nevertheless, they are not lost!

LibreOffice development team, in its constant quest of increased user satisfaction, has a workaround for you!

First grab the zip file with the required manifest. Then get the zipmerge tool that comes with libzip, and merge the manifest into the corresponding SXW file. As an example, this command line could work:

for i in <sxw-file-list>; do zipmerge temporary_sxw.sxw /path/to/sxw_manifest.zip $i && mv temporary_sxw.sxw $i; done

This way you assure that if the original SXW file already had a manifest, it will not be overwritten by the one from sxw_manifest.zip, which would not be a desirable outcome. Nonetheless, if you only have to repair one SXW file and you checked already that manifest is missing in it using tools like zipinfo, you can quietly use:

zipmerge <original-sxw-file>.sxw /path/to/sxw_manifest.zip

In order to merge the manifest directly into that file. Naturally, you can merge the manifest from the sxw_manifest.zip into the SXW file using any other zip-manipulation tool you prefer.

Enjoy and continue using LibreOffice, the free and open source office suite of reference.

LibreOffice is sometimes regarded as the Swiss army knife when it comes to opening office file-formats. Although it might be a slight exaggeration, it is a point of honour of the development team to try to allow users to load into the suite as many of their documents as possible. Every major release from the first LibreOffice 3.3 came with new and improved import filters, often for file-formats that are under-documented, if any documentation can be found at all. In this article, we would like to present the way import filters interface with LibreOffice and give to an interested developer a starting point for adding her favourite file-format among those LibreOffice is able to open.

Filters creating documents directly into LibreOffice internal structures

In general, an import filter's task is to parse the foreign document, extract from it useful information, and feed it to the application in a way it can understand. Many internal filters, like the MS Word filter, use a direct way of communicating with LibreOffice. They import the document directly into the internal structures that represent those documents. The advantage of this approach is the lack of intermediary: the document is immediately understood by the application and no additional processing is needed. The disadvantage is that this approach requires an intimate knowledge of the internal structures used and has thus a steep learning curve. The next two types of filters will correspond better to a developer that does not want to dive too deep into LibreOffice internals, yet wants to have his work done.

OpenDocument format as an interchange format

Who has not heard about OpenDocument? Hardly anybody ignores its existence. But it is also a convenient interchange format for filter writers. No need in this case to understand the LibreOffice internals apart from some hundred lines of boilerplate code that are documented in various places. It suffices to read the source document and generate a "flat" OpenDocument representation of it. LibreOffice is able to load this kind of representation as if it was loading an ODF document.

XSLT filters

The easiest way to write a filter for an XML-based file-format is using the XSLT filter dialogue. All you need is to have an XSL transform that converts a foreign XML-based file-format to the "flat" ODF, for import filters; and that converts a corresponding ODF XML to the XML used by the foreign file-format, for export filter. Once those transforms exist, the integration with LibreOffice can be done using the user interface.

Picture 1

In the Tools menu, chose XML Filter Settings, you will see listed all the XSLT filters that are already present in your LibreOffice installation along with the information about the application that is supposed to receive the resulting ODF document. Other information that can be found is about the direction of the conversion. Is it an import filter, export filter, or a filter that can import and export a foreign file-format.

If you click at "New", this dialogue will appear.

Picture 2

In the "General" tab, you will be able to chose the user-visible information about the filter: its name, the application that will receive the converted document (for instance LibreOffice Calc (.ods) for a spreadsheet converted to the OpenDocument Spreadsheet format). This information is also used by LibreOffice to group different types of documents. If you chose presentations in the file-picker and your filter specifies that it is converting into the LibreOffice Impress application, then all files having the file-extension associated with the file-format will be shown in the list.

In the "Name of file type", you will be able to describe the file-format that your filter will handle and in the "File extension" field, you will need to put semicolon-separated list of possible extensions for files in the given file-format. For instance, the extensions for the files in Microsoft Excel 2003 XML file-format will end typically with extensions xml or xls. You can add a comment in the "Comments" field. This last field is optional and you can leave it empty if you desire.

Picture 3

The next tab is the actual information about the XSL transformations that will do the conversion. The DocType field makes sense principally for import filters. The XSLT filters typedetection will scan for the string you enter there in the first 4000 bytes of the file. Since the typedetection searches for this string only in those first 4000 bytes, it is necessary to assure that the string one specifies can be found invariably in the very beginning of the file. You can leave the field empty if you desire. Then the typedetection will be done purely on the basis of an extension.

If you are writing an export filter, you will provide in the "XSLT for export" field the transform that will do the conversion from the OpenDocument XML to the file-format for which you write your filter. If this field remains empty, LibreOffice will know that you filter is not an export filter. The same is valid for the "XSLT for import" field. It will contain the path to the XSLT sheet that does the import transformation. Leaving it empty is telling LibreOffice that your filter is not an import filter. There are already several filters bundled with LibreOffice that do conversion only in one direction. For instance, the XHTML filters or the MediaWiki filter are used only to export to the corresponding file-formats.

You also have the option to specify the default template for filters that import from file-formats that don't carry style information. For instance, the bundled DocBook filter uses a template to specify styles of different outline levels. If you don't specify the template, there are two possibilities. Either your transform creates a document with full styles, or you rely on the default styles that LibreOffice uses.

The check-box "The filter needs XSLT 2.0 processor" is to be checked only if your transforms use some exclusive 2.0 features. It is nevertheless advisable to write xslt sheets of the 1.0 version. They are much simpler and, because of the performance issues of other xslt processors out there, LibreOffice uses under the hood libxslt. The fact that libxslt, has only limited support of the 2.0 features is widely offset by the performance improvement that its use brought.

Now, you are done with the integration of your filter, the dialogue in the Picture 1 allows you to test your transforms, and even to export your filter as an extension package and deploy it on different installations of LibreOffice or to distribute it over our extension web-site http://extensions.libreoffice.org

As you can see, the integration of an XSLT-based filter into LibreOffice is rather simple. That is the biggest advantage of this approach. Nevertheless, there are also some disadvantages. Despite of the migration of the XSLT engine to a relatively fast libxslt, the use of xsl transforms on large document can be relatively slow. Another disadvantage is that the transforms are not really good at converting documents where the concepts of the source and target file-formats cannot be easily mapped.

XFilter framework

The XFilter framework is the other way to integrate import filters with LibreOffice. In fact the previous XSLT-based filters use an intermediary layer that uses this framework too. The advantage of using the XFilter framework directly is the use of higher lever programming languages that allow much easier mapping of incompatible concepts, parsing of documents in several passes, as well as much more complex processing of gathered information. Moreover, this is the way to use if you need to write a filter for a file-format that is not XML-based, since the XSLT-based filters cannot be use to convert binary document file-formats.

The use of the XFilter framework is a bit more complicated then the use of the XSLT-based filter dialogue. Nevertheless, it is far from being rocket science. We will examine the steps needed for a typical import filter using the example of the recently added Microsoft Publisher filter in LibreOffice 4. For the sake of simplicity, we first start with the configuration files. You will need to craft two xml fragments, one for the filter description and one for the file-type.

Filter description:

<node oor:name="Publisher Document" oor:op="replace">
    <prop oor:name="Flags">
        <value>IMPORT ALIEN USESOPTIONS 3RDPARTYFILTER PREFERRED</value>
    </prop>
    <prop oor:name="FilterService">
       <value>com.sun.star.comp.Draw.MSPUBImportFilter</value>
    </prop>
    <prop oor:name="UIName">
       <value xml:lang="x-default">Microsoft Publisher 97-2010</value>
    </prop>
    <prop oor:name="FileFormatVersion">
       <value>0</value>
    </prop>
    <prop oor:name="Type">
       <value>draw_Publisher_Document</value>
    </prop>
    <prop oor:name="DocumentService">
       <value>com.sun.star.drawing.DrawingDocument</value>
    </prop>
</node>

The oor:name attribute gives the name of the filter used internally. This name is important because the file-type and a corresponding filter are linked using it. As to the flags, I will mention here only two or three. The others can be used just as they are. The IMPORT flag specifies that we are implementing an import filter. For export filters, the flag is EXPORT and both flags are present for a bi-directional filter. The ALIEN flag is indicating that the filter handles a non-native file-format from the point of view of LibreOffice. When used with EXPORT flag, on export to the given file-format, it will trigger a dialogue warning about a possible data loss.

The FilterService property specifies the service that will be used for converting of the document. It is necessary that it corresponds exactly to the implementation name of your import filter. Since the filter is a so-called UNO component, it uses the java-like naming. The part com.sun.star.comp.Draw indicates that the filter is a component and converts a drawing and the MSPubImportFilter is the actual name of the filter.The UIName indicates a name that will appear in the file-selection dialogue for file-formats where none of the typedetections is able to detect them.The DocumentService property specifies which service will receive the result of the conversion. Here we are converting the Microsoft Publisher files into LibreOffice Draw as a drawing, that is why the document service will be the com.sun.star.drawing.DrawingDocument. If we were converting a text document, the document service would be the com.sun.star.text.TextDocument.

The Type property specifies the file type that the filter handles. This value is important because it must correspond to the oor:name attribute of the corresponding file-type description. It is necessary that the the name of the file-type starts with the indication of the receiving application. Here we use the draw_Publisher_Document and for instance for the Wordperfect file-format, we use in LibreOffice the writer_WordPerfect_Document. But lets profit from this and have a look at the second xml fragment, the file-type one. Here is one that corresponds to our example:

<node oor:name="draw_Publisher_Document" oor:op="replace">
    <prop oor:name="DetectService">
       <value>com.sun.star.comp.Draw.MSPUBImportFilter</value>
    </prop>
    <prop oor:name="Extensions">
       <value>pub</value>
    </prop>
    <prop oor:name="MediaType">
       <value>application/x-mspublisher</value>
    </prop>
    <prop oor:name="Preferred">
       <value>true</value>
    </prop>
    <prop oor:name="PreferredFilter">
        <value>Publisher Document</value>
    </prop>
    <prop oor:name="UIName">
        <value>Microsoft Publisher</value>
    </prop>
</node>

The DetectService specifies a service that is able to determine whether a document is of the given file-format. In our case, the com.sun.star.comp.Draw.MSPUBImportFilter is able to do both, the conversion and the type-detection. In the Extensions property, semi-colon separated values indicate possible extensions for file of the given file-format. In the case of an export filter, the first extension in the list is used for saving with automatic file-extension enabled. The MediaType property basically specifies the mime-type of the file-format. The other element that links the file-format with the corresponding filter is the PreferredFilter property. LibreOffice will invoke the "Publisher Document" to convert the document if the typedetection identifies it as "draw_Publisher_Document". As to the UIName, it specifies the way the document format will be referenced in the list of file-formats in the file-picker.

Now we finished the crafting of the configuration files. It is time to create a boilerplate C++ code. Our filter not only converts from Microsoft Publisher files, but is also able to determine whether a given document is a file-format it can import. For this purpose, it has to support two services: "com.sun.star.document.ImportFilter" and "com.sun.star.document.ExtendedTypeDetection". If we were implementing an export filter, we would have to support also the service "com.sun.star.document.ExportFilter". Besides the com::sun::star::document::XFilter interface that both are bound to implement ExportFilter service must also implement the com::sun::star::document::XExporter interface and ImportFilter has to implement the com::sun::star::document::XImporter. For initialization, the filter must also implement com::sun::star::lang::XInitialization. And since the filter implements UNO servies, it should also implement the com::sun::star::lang::XServiceInfo interface.

But, let us concentrate on the interfaces that are specific to the import filter. The XFilter interface has two functions, the filter and cancel. In our example we will implement the cancel() as a do-nothing function. As for the filter function, it is the one that will do the actual filtering.

sal_Bool SAL_CALL MSPUBImportFilter::filter(const Sequence<PropertyValue> &aDescriptor) {

First, we will have to get the reference to the InputStream that represents the document we want to import. The aDescriptor is a sequence of pairs consisting of the value name and the actual value. The operator>>= will extract the value from the UNO Any (that can contain values of different types) into a variable of the requested type.

    sal_Int32 nLength = aDescriptor.getLength();
    const PropertyValue *pValue = aDescriptor.getConstArray();
    OUString sURL;
    Reference <XInputStream> xInputStream;
    for (sal_Int32 i = 0; i<nLength; i++)
       if (pValue[i].Name == "InputStream")
           pValue[i].Value >>= xInputStream;

Next we will have to specify the import service that will receive the converted document in the form of SAX messages. The com.sun.star.comp.Draw.XMLOasisImporter service is a service that receives the OpenDocument Graphics XML.

    OUString sXMLImportService ("com.sun.star.comp.Draw.XMLOasisImporter");
    Reference <XDocumentHandler> xInternalHandler(
       comphelper::ComponentContext(mxContext).createComponent(sXMLImportService),
       UNO_QUERY);

The XImporter sets up an empty target document for XDocumentHandler to write to.

    Reference <XImporter> xImporter(xInternalHandler, UNO_QUERY_THROW);
    xImporter->setTargetDocument(mxDoc);

At this point, there is enough to plug into a filter that will read the xInputStream and write the resulting XML into the xInternalHandler. On success of the filtering operation, the filter function should return true and false on failure. After the implementation of this filter function, we will have to implement XImporter's setTargetDocument function.

void SAL_CALL MSPUBImportFilter::setTargetDocument(const Reference <XComponent> & xDoc)
{
    mxDoc = xDoc;
}

In our case we just keep the Reference to XComponent in a member variable that we used in the previous snippet to set up an empty target that receives our imported document. And that would be all for the integration of an Import filter. For an export filter we would have to implement also the XExporter's setSourceDocument that is basically symmetrical to XImporter's setTargetDocument.

It is good to note that another way of integrating of filters into LibreOffice could be using the com::sun::star::xml::XExportFilter and com::sun::star::xml::XImportFilter interfaces that are grosso-modo equivalent to the described method. The difference is that the FilterService in the configuration xml file will be in this case always com.sun.star.comp.Writer.XmlFilterAdaptor and the actual filter component, as well as the target and source services are specified in the configuration file in the UserData property. But this is just for an anecdote, since the method I described in detail is much more generic.

When we were creating the xml configuration files, we said that the com.sun.star.comp.Draw.MSPUBImportFilter component is able to do also the type-detection. For that purpose, it must support the com::sun::star::document::XExtendedFilterDetection interface, and thus its detect function.This function should return the string corresponding to the type name in the configuration file if it detects the document and an empty string for the cases when it is not able to identify the document.

OUString SAL_CALL MSPUBImportFilter::detect(Sequence <PropertyValue> &Descriptor)
{
    OUString sTypeName;
    sal_Int32 nLength = Descriptor.getLength();
    sal_Int32 location = nLength;
    const PropertyValue *pValue = Descriptor.getConstArray

();
    Reference <XInputStream> xInputStream;
    for (sal_Int32 i = 0; i<nLength; ++i)
       if (pValue[i].Name == "TypeName")
            location=i;
       else if (pValue[i].Name == "InputStream")
           pValue[i].Value >>= xInputStream;

As in the filter function we need to extract from the sequence the InputStream that we will examine. There is one difference, we will keep the reference of the TypeName property, so that we can fill it with the name of the type in case we detected it. The detect function should fill the variable sTypeName with the right string in case the detection was successful. And it is in this case that we will specify this information to the Descriptor and return the name of the type.

    if (!sTypeName.isEmpty())
    {
       if (location == Descriptor.getLength())
       {
           Descriptor.realloc(nLength+1);
           Descriptor[location].Name = "TypeName";
       }
       Descriptor[location].Value <<= sTypeName;
    }
    return sTypeName;
}

It would be not true to say that this is all that is needed to integrate a filter into LibreOffice. There are still some ten to fifty lines of code needed for the implementation of the generic UNO boilerplate, an xml file for the UNO component registration during the build and some makefile changes. Nevertheless, those changes are just trivial and can be done by mimicking existing filters like those in the writerperfect module of the LibreOffice code.

Getting involved

Free software is about people and the LibreOffice projects values highly all contributors, regardless of the size of their contribution. The community is thrilled to welcome anybody that wants to lend hand to make the software better. And why not you? If you think that writing filters for LibreOffice is enough fun for you, there are plenty of dedicated developers ready to help you either on the developer list libreoffice@lists.freedesktop.org or on IRC at #libreoffice-dev channel of the Freenode server. Just drop by and we will help you to write your first filter. We guarantee that you will enjoy and stick with the project.

Just a quick note to announce that I released Exempi 2.2.1. It was long overdue. It is mostly a couple of bugfixes.

Note: so that there is no misunderstanding, since people see this on Planet Mozilla, this is not a Mozilla project. But it is completely Free Software.

Here is the short Changelog

• Bug #54011: Use POSIX API for files on MacOS. (Misty De Meo)
• Bug #58175: Replace OS X FlatCarbon headers. (Misty De Meo)
• Added a manpage for exempi(1).
• Added the -n option to the command line for arbitrary namespaces.

Next release will be 2.3.0 and will integrate the latest Adobe SDK used in the Creative Cloud.

There is no question about that.

I just switched from an Android phablet made by Samsung, device I came to hate for many reasons, to a Firefox OS Geeksphone Keon. That was my second Android phone, I switched because I got it for free^[1], needed a carrier that worked better than the failure that is WIND Mobile on which I was using my Nexus One^[2] and said Nexus One was just abandoned in OS upgrade by HTC AND Google after 22 month. I have to admit I missed the Nexus One, still, as Samsung didn't make Android better, quite the opposite.

Back to the point. I got that Geeksphone Keon, provided by my employer: Mozilla.

This is not a review of the phone, BTW, and all of this also applies to the just released Firefox OS phone in Spain.

On my Android phablet^[3] I used 4 applications: the web browser, a twitter client (not Twitter's own though), Instagram and Foursquare.

On my Firefox OS phone, I had to scrap the last two. Why? Because despite requiring an internet connection and having some sort of web interface, their are unusable on the web.

Web browser

On Android I used Firefox for Android as my web browser. It is currently the best solution for web browsing is designed to protect your privacy and to run on more devices than Google's own Chrome. Call me biased if you want but truth is I have been using Firefox on the desktop too.

Firefox OS web browser is basically the same thing.

Twitter

Twitter is a bit hurtfull. It is designed from the ground up to be used as a web application. Twitter has a mobile version that is meant to work well on small screen. They even have a packaged version for the Firefox OS Marketplace. Where it hurts is that Twitter web UI remains awful, either deliberately (given that the iOS client is awfull too) or because we got spoiled by third-party clients. On Android I was using Twicca (no source code) or Twidere (broke a bit at one point), but it should be noted that Twitter gave the finger to third parties when they added restriction on the development of client ; as well as bickering with Instagram to not show their content inline.

They get almost full marks for being a web app and treating it as first class.

Foursquare

On the desktop, if you go to Foursquare you get a decent web application, albeit you can do the major feature that Foursquare calls for: check-in.

On mobile, if I visit the website on Firefox for Android I get prompted to download an app.

On Firefox OS it is worse. Looks like their detection fail and they offer the desktop website that is mostly unusable on such a small screen. I filed bug 878132 for our tech evangelism to eventually have a look at.

Seems like they didn't go all the way to make it relevant on mobile web. Sadly. What was an experiment I started by the end of last year when I signed up for the service stopped here right at Firefox OS. It seems that I don't need it. They lost a user.

Instagram

This one is the worst of the worst. First and foremost their web interface for desktop is very limited. Secondly, it doesn't scale at all on mobile - some content scale better than other. Third, they bickered with Twitter so that their content is not viewable inline.

Why does that last one matter? Try viewing the instagram content in the Twitter mobile web client.

I give a F as a mark.

Conclusion

Simply make your mobile app web based. It will run on iOS, Android, Firefox OS, Blackberry, etc. and people will be able to follow when they change phone and you won't need to spend a lot of resources for each platforms.

Also if you really want to have a packaged app, remember there are technologies like PhoneGap whose purpose is exactly that.

Attentive reader of this blog remembers that, besides improvements in the most frequently used file-formats, each major release of LibreOffice adds to the list of document file-formats that are freed from the dungeon of vendor lock. In a collaboration with re-lab's Valek Filippov and (then GSoC student and now Lanedo's LibreOffice developer) Eilidh McAdam, LibreOffice 3.5 brought the possibility to open and see the most commonly used Visio files to the FLOSS world. LibreOffice 3.6 was able to claim the most comprehensive coverage of CorelDraw file-format with the ability to open even the oldest CorelDraw 1 and 2 files that modern versions of CorelDraw are not able to open any more.

The latest major release of LibreOffice was also full of goodies. First, the fruitful collaboration of re-lab's Valek Filippov with (then GSoC student and now amazon.com employee) Brennan T. Vincent produced the first ever possibility of reading Microsoft Publisher files in the FLOSS world. Second, with the advent of Microsoft Office 2013 and change in the Visio 2013 file-format, LibreOffice extended the coverage of Visio file-format to all files any version of Visio ever produced.

LibreOffice 4.1 release is approaching quickly. And that is an excellent news for bad teenage poetry and other literary production from the late 80s and early 90s. With the up-coming new release, LibreOffice extends support for a host of pre-OSX MAC text formats. This is a result of a continuous effort to open as many legacy file-formats as possible to our users, and help them to settle for ODF.

This particular improvement was possible thank to the integration of libmwaw written by Laurent Alonso, LibreOffice contributor and already co-maintainer of libwps and of the Microsoft Works import filter inside LibreOffice. The horsepower doing the conversions, libmwaw is one of the libraries from the libwpd family. In the same way as libwps, libmwaw reuses libwpd's interfaces and the ODF generator classes in libodfgen in order to convert its callbacks into an xml stream in flat ODF file-format. The import filter lives in the module writerperfect.

The supported file-format include Microsoft Word for Mac from versions 1 to 5.1, Mac versions of Microsoft Works, different versions of ClarisWorks and AppleWorks, to name but a few. The list of supported file-format and of imported features is increasing literally every day. This promises further good news with every minor release of LibreOffice 4.1. More teenage poetry and bad litterature will be freed from the pit of discontinued software products.

After having found a way to get screenshots of some sample documents in their respective generating application, we are able to satisfy those readers that are hungry for pictures. First is a sample document in Mac Word 5.1 (1992) file-format opened in the originating application and in the up-coming LibreOffice 4.1:

Following is a simple document with picture produced by Write Now 4.1 from about 1993. It demonstrates the reason why LibreOffice is frequently called the "Swiss Army knife" of file-formats:

Following is an example of conversion of a document in MacWrite Pro 1.5 file-format from 1994:

And, last but not least is an example of conversion of a wordprocessing documents in AppleWorks 6.0 from the late 90s. The software was discontinued by Apple with the end-of-life of their PowerPC series. But LibreOffice can resurrect your documents:

Pretty exciting news! But the most exciting thing is that you can be part of this adventure. Join the fun by submitting bugs or by fixing your personal itches. So, if you want to help, patches can be sent to libreoffice-dev mailing list. And, do not forget to find a way to join the #libreoffice-dev channel at irc.freenode.net in order to meet other developers. We can promise you that you will have a lot of fun in the LibreOffice community.

C++ 11 is now available in both gcc and clang. That mean it is really available where it matters.

Using C++ 11 in your project (with autoconf).

First if you use autoconf, you have to detect it. The autoconf archive has a macro. Download the .m4 definition and put it in your m4 directory in your project.

In the configure.ac, add the following line:

AX_CXX_COMPILE_STDCXX_11(noext,mandatory)

Make sure it appears after

AC_GNU_SOURCE

This is will make configure detect C++11 support, without GNU extension (I tend to avoid these in general) and fail if it doesn't exist. If you prefer to make it optional, read the above documentation that has more details.

The interesting features

I'm interested in several features from C++11.

1. auto to automatically deduct the type where it can. Ever gotten annoyed by the long type name for iterators of containers? Just use auto instead.
2. Lambda: now you can write lambda functions like in Python or JavaScript. This is overly convenient when you iterate over containers or use std::for_each().
3. The smart pointers: I was using the one from Boost, then the one from std::tr1::. Just replace with std::
4. std::bind and std::function to replace Boost own versions.

There are more, I'll talk about it when I get to look at them.

There is now again the period of the year when the results of Google Summer of Code selection are public. As for LibreOffice project, we have got 13 slots this year. We love you, Google! We really do!

Nonetheless, we had much more good applications then the slots and we had to do hard choices based on a variety of parameters. And the final line-up that came out is:

Project		Student
Adding alterating row coloring to database ranges and supporting new structured reference syntax		she91
Code completion in the Basic IDE		stalker08
Extend support for Document Management Systems		Cuong Cao Ngo
Implement Firebird SQL connector for LibreOfficeBase		Andrzej Hunt
Implementing an about:config functionality		Efe Gürkan YALAMAN
Implementing Proper Table Styles in Writer		Ivan Nicolae-Alexandru
Impress Remote Control for iOS		LIU Siqi
Improve toolbars in LibreOffice		Prashant Pandey
Improved Android / Impress Remote Control		Artur Dryomov
Slide Layout Extendibility		Vishv Brahmbhatt
Use Widget Layout for the Start Center		Krisztian Pinter
VLC integration into LibreOffice		Minh Ngo
Writer: Border around characters		Zolnai Tamás

Congratulations to the selected students. We expect you to be bonding hard during the community bonding period that just started. Your presence on IRC and even start of the hacking is required now!

For the students that unfortunately could not be selected, do not be discouraged. Your Easy Hack patches made a real difference, sorry it did not work out this time. The LibreOffice community is always welcoming and you can learn a lot just by staying around and working at your pace on your chosen Easy Hack.

Mozilla is 15 and that's 15 years of fighting for the open web. I remember the source code release, I built it on in Pentium 166 with 64MB of RAM - a Debian box. I maybe less RAM than that, I forgot. It was huge.

Since, the web has gone forward big times, and Firefox helped users to take back the web by bringing down the IE supremacy and focusing on a standardized web technology.

I have great hopes for the future of the free web.

Google did shutdown Reader, their feed aggregator. Speculation is that it is to promote the use of the proprietary publishing silo that is Google+, and I'm not saying as a Google+ grudge I might hold, I actually believe it might be one of the considerations.

Imagine a second if all the content was pushed exclusively to a popular silo like Twitter, Facebook and Google+: it would be confined to these environments and people wouldn't be able to aggregate elsewhere. Now what if one of these hugely popular silos disappeared. It has happened, it can happen again, I have numerous examples. And I am still look for the Google+ or Facebook feeds, while it is clear that Twitter already removed them.

With RSS^[1] all we need is a different aggregator to pull the feed. It would still work. And that's what happening with Google Reader user base: they are moving to other platforms that offer the same feature, either web based, or using desktop software.

Let's have this a learning step and continue to focusing on open standards for publishing. Let's continue to provide feeds. Let's continue to request feeds. And more importantly, us software hackers, let's continue to provide awesome libre software to do the job and on which we can reliably build upon.

It is the new year. We have a tendency to put artificial starting points in time to want to (start to) do things, something like the "new year resolutions". I don't really abide to that because I believe you should do things when you want to, have to or can. You don't need a January 1st or some sort. This year it happens that the new year almost coincide with my timeline. Two weeks into the new house in Montréal, this mean that for once I can use that as the starting point ; or not.

Anyway.

Happy new year, and remember, be excellent to each other !

It is true that the support of the most used Microsoft Visio file formats in LibreOffice will celebrate 1 year next February. And I will gladly have a birthday talk with any of you who will be freezing in Brussels during the next FOSDEM 2013. Nonetheless, even though libvisio was in development for several months already, the Visio story was far from finished when we released that day. As I already mentioned in another blogpost concerning reverse-engineering of file formats, assessment of a conversion quality in this kind of cases is illusory before real users get to stress-test it with real-life documents.
Since the first release of our filter in LibreOffice 3.5.0, we were improving it thanks to bug reports from our users. It is a big thank you that I would like to say to all those that took the bother to submit reports in our bugzilla. Without you, guys, this filter would be only a moot exercise.
But wait... Do I write this blog now only to thank the people who contributed to the current quality of the filter? Yes to a big extent! Nevertheless, I know that the distinguished readers of this blog would like to have some news. And, yes, we have some news.
The libvisio library underwent heavy re-factoring as we started to understand more and more details about the underlying file-format.

1. A particular bug report about files imported as empty pages provided us with a document structure that we did never see before. This resulted in a more generic parser and unification on the way we parse master shapes and visible pages.
2. This re-factoring in its turn allowed us to extend our file-format coverage to all earlier binary Visio file-format versions. We now support all binary Visio documents starting from Visio 1 (released in 1992).
3. Extending the support to earlier file-format versions allowed us to better understand the development of the file-format, to find more information that we did not parse before, and improve the conversion quality for other binary versions too.
4. Another re-factoring came with our work to support the XML-based Visio file-formats, namely the "XML Drawing" also known as *.vdx; and the Microsoft Visio 2013 new file-format, known as *.vsdx.

So the news is that LibreOffice 4.0.0 will be able to open ALL Visio files starting from Visio 1 (release in 1992) until Microsoft Visio 2013 (released just some weeks ago).
And since the readers of this blog are more interested in pictures than in pointless words, here come some candies for your eyes:

File opened in Visio 1.0		The same file opened in LibreOffice 4.0.0 beta1

VSDX File opened in Microsoft Visio 2013		The same file opened in LibreOffice 4.0.0 beta1

So, download the LibreOffice 4.0.0 beta1 and help us testing the new big release. We are interested in bug reports that help us to improve our quality. And for those that would love to support us with donations, just click here:

It has been a long time without communicating with the distinguished readership of my blog. There was a hard decision to be made between producing code and producing literature. The code won until now. But now I have found a time to lift my head up from the coding, so the literature is back.

Many of you might be wondering what happened since my post about the text support in CorelDraw files from last June. Things are going pretty well. Since the CorelDraw import filter was released with LibreOffice 3.6, the users started to use the feature and report bugs. We were working on fixing them and improving the libcdr's quality.

Quick overview of reverse-engineering process

From my discussions with our users and developers on-line and during some of the conferences that I attended, I realize that there is a slight misunderstanding in the large public about how the reverse-engineering works. So, here are some thoughts that may help understand it a bit more:

At the beginning of the process, there is a file-format. We don't know anything about its internal structure. There is no documentation whatsoever about it. One tries to generate a file in this file-format and examine it in hexadecimal viewer. Next, one tries to operate some little change in the document and examine what changed in the file itself. Eventually after many iterations, one might find regularities and some structure that helps to divide the file into several sections or blocks of more manageable size. It is essential in this phase that one can encode this information into some kind of introspection tool, since a plain hexadecimal viewer is not a very productive tool in the long run. We use for introspection of documents Valek Filippov's oletoy, a python tool that stores our knowledge about the structure of different file-formats.

Once there is enough information about how to parse the document structure, the next target becomes to get some visible results. In order to save time and get visible results in a short time, all libraries such as libcdr or libvisio, use the libwpg's interface. Reusing this interface means a considerable saving of time, since there are already working generators of ODG and SVG from the callbacks of this interface. Having visible results soon in the development/reverse-engineering cycle also allows visually asses the import results and correct them if necessary. Eventually, one can realize the absence of necessary information and try to go back to reverse-engineering to find it.

Users' feedback is essential

The support of reverse-engineered file-formats is a constant work-in-progress. A subtle dance between implementation and information digging. In this process, the user feedback is an essential element. The theories about the meaning of some information inside file hold only until a file comes to falsify them. Even a complex file generated by a developer is easily beaten by real life documents. And each file that shows a "weird" bug is advancing the understanding of the file-format. Let us look at this example:

After the release of LibreOffice 3.6.1, we got a not so good assessment of the quality of the CorelDraw import filter in the heise.de' c't review. Those of you that understand German can delight in the nuanced evaluation:

Ein neuer Import-Filter in Draw öffnet jetzt auch CorelDraw-Dateien, was uns im Test allerdings nur mit sehr einfachen Zeichnungen fehlerfrei gelang. In dieser Form ist er schlicht unbrauchbar.

Which can be mildly translated into English (given the understatements so common in en-GB):

A new import filter in Draw opens now also CorelDraw files, which we managed to do without errors only with very simple drawings. In this form, it is rather unusable.

Since we are really concerned about the quality of our software, we are thankful for any bug report whether it is brought to us in a friendly or other manner. This specific bug report helped us to understand how are stored in newer CorelDraw files chains of matrix transforms. And since a picture speaks louder then thousand words, compare the document c't was refering to opened in LibreOffice 3.6.2 and then in LibreOffice 3.6.3, after we fixed the position bits.

File opened in Libreoffice 3.6.2		The same file opened in LibreOffice 3.6.3

So feel encouraged to submit bugs against the CorelDraw import filter, or — even better — send us patches for your favorite itch.

Broken Lock by lyudagreen, on Flickr

A big North American online travel booking system still store passwords in plain text. Worse: they claim they take your security seriously. Here is the excerpt of the confirmation email you get when you register:

USERNAME: USER@EMAIL.DOMAIN
PASSWORD:  We're serious about security. Since your
password is confidential, we won't repeat it here. However, if you ever
forget your password, you can always request a reminder

Yes, the email has been capitalized.

The other day I wanted to book some airline tickets, so I returned to the website. I had forgotten the password. No biggie, I follow the "lost password procedure" and chose the "email" instead of the still idiotic "security question".

Guess what? I didn't get a link to reset my password, or a temporary password. No. I got my password sent in plain text. Worse. It was in UPPERCASE and the passwords are case insensitive in the system. Wow. Just wow.

PS: this is not the corporate travel booking system we use at Mozilla.

In my previous post ''What happened to all the pioneers in personal computing?'' I forgot a few notable companies.

• Acorn: I mostly forgot to talk about Acorn Computers, probably because Acorn computers were only popular mostly in the UK and were quasi unknown in France. The BBC Micro is their most popular 8-bit computer, released in 1981. But what came later was the game changing for the industry today. In 1987, they released the Acorn Archimedes, a 32-bits desktop computer powered with a RISC processor. It was faster than most of the competition like the Atari ST and the Amiga. Its CPU was the ARM (Acorn RISC Machine). This led to the spin-off ARM Ltd, that was in charge of the development of the ARM CPU. A partnership with Apple that wanted something for the Newton led to further development and the first license ; the RISC PC became the last generation of Acorn computer. Today, ARM is the most used CPU design for embedded systems: cell-phone, DSL routers, iPod, smart phones, PDA, iPad, etc. Acorn Computers moved on to build set-top boxes, after selling the RISC PC business, and in the end was absorbed into Broadcom in 2000 to become the DSL unit. ARM Ltd is now known ARM Holdings and license the IP for the ARM CPU to manufacturers.

• Compaq: Compaq major achievement was to be the first manufacturer of 100% IBM compatible PC after they successfully cloned the BIOS via clean room engineering, 1982. The BIOS was the cornerstone of IBM PC compatibility as just running MS-DOS wasn't enough: the Disk Operating System has so little feature that programmers mostly called into the BIOS interruptions to write their applications. Phoenix Technologies who followed in 1984 offering their own BIOS clone. Compaq made the first 100% IBM PC compatible portable computer, and then manufactured lot of quality IBM PC Clones, including the first with an Intel 386, being ahead of IBM itself. After buying Digital Equipment Corporation, it was bought by HP in 2002 and the PC product lines were merged, where mostly Compaq products in the business line were rebadged HP.

As I was writing this second, post, Ars Technica published From Altair to iPad: 35 years of personal computer market share where they relate the 35 years from the Altair to the move to the iPad as a personal computing device.

The Commodore 64 is 30. The TRS-80 is 35. But what happened to all the pioneers of the Personal Computing era?

• MITS. They made in 1974 the Altair 8800. It was a micro-computer sold in kit (or assembled), running the Intel 8080 processor. The first one ; it sold quite well, but was not, at first, usable out of the box as it didn't have software. Also it is the Altair that led to the creation of Microsoft who sold their BASIC to MITS. For Microsoft, we know the rest, for the Altair, the computer is almost forgotten, so is MITS, as the company got sold. One notorious clone of the Altair was the IMSAI 8080 ; if you have seen the movie Wargames (1983), you have seen one.

• Tandy: The TRS-80 appeared in 1977 and become quickly one of the most popular PC, selling until being discontinued in 1981, replaced with the Model III. It was much cheaper than the Apple 2 and was widely available in the Radio Shack stores (several thousands in the US). Zork, the text adventure game was ported and released on the TRS-80 first. Tandy was so serious about making computers that they bought GRiD, and later started making IBM PC clones. Tandy sold off the computer division to AST in the early 90's. The TRS-80 was nicknamed Trash-80 probably because of all the quirks in its design.

• GRiD Computing: GRiD is not that well known from the general public, but they were the first company designing laptop computers that were attaché-case sized. The GRiD Compass was released in 1982 and was marketed to CEOs. The GRiD Compass 110 featured the clam-shell design so well known today that GRiD patented. In 1989, the GRiD Compass 1101 was the first laptop to fly on the Space Shuttle. GRiD also pioneered in tablet computing. They got bought by Tandy.

• Commodore: The Commodore 64 was not Commodore first computer, nor their last, but was hugely popular, both in North America and in Europe, a best seller with between 12.5 and 17 Million units sold. It just celebrated its 30 years. In 1984, Commodore International founder Jack Tramiel left the company. After that, Commodore went on to buy a startup called Amiga Corporation to make the Amiga line of computers, that ended up competing with the rival Atari. The company filed for bankruptcy in 1994. Today the ghost of the Amiga still lives in the heart of fans and hobbyists. I wish my brother had preferred getting a Commodore 64 rather than a TI99/4A at the time.

• Atari: The story of Atari is more convoluted. Atari Inc. was the company that sold the first video game: Pong. In 1979 they released the Atari 400 and 800 8 bits computers. In 1984, Warner Communication, Atari Inc. owner, sold off the home computing and console division to Jack Tramiel - Commodore International founder - to form Atari Corporation. This is how the Atari ST end up being released in 1985, competing directly with Commodore's Amiga. It was more popular in Europe, with Germany being the key market, than in the US. The whole line was cancelled in 1993, and in 1996, Atari reverse merged with another company, to be sold to Hasbro in 1998, mostly for the IP (game rights) and brand.

• In Europe, there was Sinclair, Amstrad, etc. None of these make personal computers anymore.

So what is left from the pioneers?

• Microsoft, that sold BASIC to MITS (and several other manufacturers including Apple), and later MS-DOS to IBM is still here, doing mostly the same thing.

• IBM is still around, after launching the IBM PC in 1981, using Microsoft MS-DOS (and BASIC), they failed to gain traction in the OS market with the failed OS/2. IBM sold the PC division to Lenovo in 2005.

• Apple, after the Apple 2 gained traction with the Macintosh they launched in 1984. After catastrophic mid-90's, they got put back on track and are now the number 1 laptop vendor in a market dominated by Microsoft Windows machines, and make the best selling smartphone, the iPhone.

Am I missing anything?

Update: part deux

Over the last few years I've been fortunate enough to hack on Calligra and Abiword, adding support for the RDF/XML that can be stored as part of an ODF document. Both suites can also interact with each other, allowing RDF to move over the clipboard along with the text content.

There are some things abiword can do with RDF that Calligra currently can't. These include highlighting the parts of the document that have RDF associated and initial support for capturing relations between things in RDF. Such relationships from RDF can give back to the user right off the bat. For example they can be useful for navigating the document by semantics, moving from a child to their parent, or the cat to it's owner. RDF also opens up document computing to other possibilities like navigating by time rather than by the linear sequence of pages.

I am currently looking to do some more development around ODF. It would be wonderful to do some more indepth hacking on either project as they both have a very nice, welcoming, open source team behind them. If anybody knows of some sponsored hacking floating around for these tools, please get in touch :)

I recently committed a small change to Calligra to move back to using intrusive reference counting for some non graphical RDF objects. While Calligra can use marble to allow editing locations from RDF, I used marble at a level in the calligra stack that isn't optimal, so have to shift that to a plugin to allow it to be easily accessible to distribution builds.

Firefox 16 uplift to Aurora is today. This version will have Accessibility enabled on Mac, finally, but you must either force enable or use VoiceOver. It should work for basic tasks, albeit there is some serious performance problems with VoiceOver I'm investigating.

Also, coming soon for Firefox 17: handling properly image maps.

I am happy to announce the upcoming book of my dear wife. A must read for all interested in intellectual property, in access to copyrighted materials and in development issues.

This book originates from a PhD thesis defended at the Graduate Institute of International and Development Studies, Geneva, Switzerland. It has been awarded "summa cum laude" mention.

Check, please, with your libraries whether they know about the book and advise them strongly to purchase it for the biggest good of the humanity :)

One thing puzzling with YouTube HTML5 support is the message "this video is currently unavailable" which could mean a lot of things. The actual translation is "we need to show you ads and you need Flash for that".

If should be noted that there is no problem on mobile platform, Android or iOS, the video is shown.

I don't know if you noticed, but when you connect a Nexus One or a Samsung phone (Gingerbread or ICS, tested with a SGS 2 or Galaxy Note) to your Mac, the phone isn't recognized as a camera.

There is a difference between the Nexus One (stuck to Gingerbread) and the Samsung. The Nexus is USB Mass Storage (ie the phone is seen as a USB disk) while the Samsung is MTP (a variant of PTP, the USB standard for still image cameras). But in both case, the MacOS digital camera support (Image Capture, iPhoto or Aperture) recognize it but do not show anything. Adobe Lightroom is in the same boat (I'm not sure if it uses the OS capability or reimplemented it). This is because Android butcher the implementation of the Design rules for Camera Filesystem. See Android bug 2960 where you'll notice that it was largely ignored by Google despite even having a patch.

For the Nexus One this does not prevent from manually copying the images. But Samsung.... one would think they would have fixed that, but obviously they didn't. To make things worse, Samsung doesn't use Mass Storage but MTP, which mean that there is no way to just copy files from the camera^[1]. That last bit is utter fail.

Update (June 21st): from the comment, apparently I can set the Galaxy Note to be as USB Mass Storage. It is complicated, needs to be done manually, require disabling USB Debugging (it will do it for you, but not reenable it), etc. In short they turned something relatively simple to something overly complex and unfriendly. Worse, it is so many to reach the dialog where like on the Nexus One, you can tap to enable Mass Storage. The positive side is that you can't enable Mass Storage without unlocking the phone, which is a security feature.

Some update about Firefox accessibility on Mac:

• Accessibility on Mac has been disabled in Aurora 15 (and Nightly) shortly after the uplift early June. This was done because accessibility seemed to be instanciated for more than just accessibility clients, causing several unforeseen performance issues.
• Accessibility on Mac has been re-enabled in last night Nightly 16 build for Mac. The changes are that now we whitelist VoiceOver before starting accessibility on the Mac. We also added a switch in about:config to force enable (bypass the white listing) or disable.
• I have a current patch queue that include dealing with tab panels properly (bug 750612), text reading (bug 718625) and WAI-ARIA landmarks (bug 718700).

Using about:config: accessibility.force_disable. This option has 3 values:

• 0 (default): do as usual
• 1: disabled. Accessibility will not be started.
• -1: force enabled. Accessibility will always start when requested, even without voice over.

This also works on Windows (the value -1 is unused) and soon on Linux with atk (I have to finish it)

I hope to get more rolling before we uplift Aurora 16.

Pleasantly surpised we made it into the great LWN

Uff, it is done!!!

We started to work on the text support inside libcdr already before the Libre Graphics Meeting in Vienna. We worked hard during the talks and the long evenings after having eaten some portions of Wienerschnitzl.

Now we are proud to announce that we managed to release yesterday libcdr-0.0.8 with "basic initial primitive [u]ncomplete" (further BIPU) text support. At the moment, we are supporting only a couple of parameters as a font face and font size and we are able to detect the encoding and produce a corresponding utf-8 string. Far from being perfect, it is nonetheless a milestone, because in the FOSS world, there was no support for CorelDraw text before.

We know that you prefer to look at nice pictures instead of reading bad text. So, this gives your heart's desires.

A simple document with text in CorelDraw 7:

The same document opened in a build of LibreOffice from yesterday:

At the moment, libcdr is able to convert text in CorelDraw documents from versions 7 to 16. Nonetheless, we know already roughly how to read it in files of lower versions and we will add the support for next release. In the same way, we will extend our support of other text properties, like font colour, transparency, effects, paragraph alignments, character positions, etc.

How can I test it? All this goodness will be part of LibreOffice 3.6.0 release. You will be able to test the text support in the 3.6.0 beta2 pre-release. For the brave, any of the daily builds that are built from a code checkout after June 11th also include libcdr-0.0.8 and thus the text support in CorelDraw files.

As usual, this is a free and open source software project and, as such, it delights in developers that want to help. So, if you feel the itch, patches can be sent to libreoffice-dev mailing list. And, do not forget to find a way to join the #libreoffice-dev channel at irc.freenode.net in order to meet other developers. We can promis you that you will feel at home in the LibreOffice community.

Yep, I deleted my LinkedIn account. Despite the fact that I got no value from it, the leak of 6.5M unsalted password hashes was just the icing on the cake. For so long they had a deficient SSL support, they ask to decrypt a captcha to login and lot of other stupidities. And their mobile app steal or leak personal info like your iPhone calendar.

I should have done that a long time ago. When they asked a reason I typed in "too dumb with security"

You know where you can find me.

As Sophie Gauthier announced in the language of Voltaire, LibreOffice was branched for the beta phase in view of the 3.6 release. This is a major step in order to bring the features we were working on during the last half a year to the end users. But, it is also oportunity to bring to the main codebase all the nifty nice features that were developed in feature branches and targeted for the next big release, presumably the 3.7.

It is this way that the first version of our new Microsoft Publisher import filter landed to the master. This filter is developed by Brennan Vincent from the University of Arizona in the frame of the Google Summer of Code. Although being a work in progress and supporting for the while only the Publisher 2003 file-format, the progress is spectacular. Brennan has been busy like a bee even long before the start of the program. After only two weeks from the official kick-off, we have a first (non-)release, libmspub-0.0.0.

And as the careful readers of this blog already know, an image speaks louder then thousand words, here are the pics:

A random document from the Internet opened in Microsoft Publisher 2003:

The same document opened in LibreOffice master build from yesterday:

With Valek Filippov, we have a lot of fun mentoring this project. If anybody of the distinguished readership wants to join this effort, the code of libmspub lives in LibreOffice freedesktop.org repository. The patches can be sent to libreoffice-dev mailing list. And, do not forget to find a way to join the #libreoffice-dev channel at irc.freenode.net in order to meet other developers.

You will never regret the decision to get involved in LibreOffice.

A very happy first week to my baby daughter Amélie! She was born last Sunday, May 27th, and she and her lovely mother are doing very well. During the day she is total cuteness, rainbows and unicorns, while at night she turns into a hungry monster! A cute monster, but still… :P

Welcome to this world Amélie!

How to take a screenshot on an Android phone, a Google Nexus One in my case. I have to document it, because "home + power" like on an iPhone (or any iOS device) is far too complicated.

Warning: this post contain whole parts of ranting and sarcasm.

1. Configure your phone to allow USB debugging.
2. Install the Android SDK
3. Connect the phone over USB
4. Start ddms from the Android SDK
5. Select your phone.

Kaboom. It crashes.

01:42:04 E/ddms: Failed to execute runnable (java.lang.ArrayIndexOutOfBoundsException: -1)
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.ArrayIndexOutOfBoundsException: -1)
	at org.eclipse.swt.SWT.error(Unknown Source)
	at org.eclipse.swt.SWT.error(Unknown Source)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
	at com.android.ddms.UIThread.runUI(UIThread.java:517)
	at com.android.ddms.Main.main(Main.java:116)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
	at org.eclipse.jface.viewers.AbstractTableViewer$VirtualManager.resolveElement(AbstractTableViewer.java:100)
	at org.eclipse.jface.viewers.AbstractTableViewer$1.handleEvent(AbstractTableViewer.java:70)
	at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Table.checkData(Unknown Source)
	at org.eclipse.swt.widgets.Table.cellDataProc(Unknown Source)
	at org.eclipse.swt.widgets.Display.cellDataProc(Unknown Source)
	at org.eclipse.swt.internal.gtk.OS._gtk_list_store_append(Native Method)
	at org.eclipse.swt.internal.gtk.OS.gtk_list_store_append(Unknown Source)
	at org.eclipse.swt.widgets.Table.setItemCount(Unknown Source)
	at org.eclipse.jface.viewers.TableViewer.doSetItemCount(TableViewer.java:217)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalVirtualRefreshAll(AbstractTableViewer.java:661)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:635)
	at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:620)
	at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1430)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1365)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1328)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1428)
	at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:537)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1387)
	at com.android.ddmuilib.logcat.LogCatPanel$LogCatTableRefresherTask.run(LogCatPanel.java:1000)
	at org.eclipse.swt.widgets.RunnableLock.run(Unknown Source)
	... 5 more

En voila. You still haven't taken a screenshot.

And for the record, I'm aware that Android 4.0 can do it, but Google still hasn't provided an update for the Nexus One (their first flagship device) and is unlikely to do it. That's not really encouraging into buying a newer device.

Update: upgraded to platforn tools version 11 and still the same problem.

For the last few weeks my spare cycles have been mostly spent on the Guacamayo Project; this is something that myself and Ross have been toying with for a while, and it’s probably time to say a bit about it.

In a gist Guacamayo is a specialised Linux distribution for networked multimedia devices; I say specialised, because the aim is not to produce yet another rehashed desktop distro with a bit of multimedia functionality on the side, but a system built from ground up for a pure multimedia experience.

The clearly defined focus allows us to do one thing in particular: we can ditch the traditional Linux desktop! The Guacamayo aim is to provide an intuitive gateway into a multi media world; the traditional desktop metaphor made up of workspaces, applications, documents and no end of toolbars and menus does nothing but stand in the way. Considering most of us have to put up with that sort of mess during working hours, I think we deserve better when it’s time to chill out.

Ditching the traditional Linux desktop has some other inherent benefits; we can forget about legacy technologies, not least the venerable X11 windowing system, and instead choose what makes best sense for creating that sort of user experience we are after.

So what are we doing:

• Distro based on Yocto; this was an obvious choice. Guacamayo targets multiple hardware architectures, so a proven cross-compilation environment is a must, plus Yocto makes crafting a carefully defined distro from scratch if not an easy, then a practical possibility,
• UPnP integration provided by rygel,
• PulseAudio for the sound,
• GStreamer as the core medial framework,
• Shell based on OpenGL, provided by MediaExplorer, aka MEX. Like Yocto, this has been an obvious choice, since MEX provides a really cool, modern, intuitive interface.

Supported HW? We are not focusing on any HW in particular. Our aim is to create a distro that could be used on a broad variety of suitable HW.  The current development is done using the Zotac zbox (Intel Atom) and the Beagleboard (Arm Cortex A8), and we fully intend to support Raspberry PI (eagerly awaiting HW).

We did our first release code named ‘See No Evil, Hear All You Want!’, aka 0.2, last week. As the name suggests, this is a limited functionality audio-only release, to get folk interested to come along and start testing and contributing. The next stable release is planed to include MEX running under X11, as a stepping stone toward a pure OpenGL system beyond that.

If you are interested, the source is here, you can drop by #guacamayo on Freenode, or follow @MetaGuacamayo on Twitter.

Google Summer of Code Mentor Summit 2011

What is a community 

• People with a common purpose or goal
• Communicating with each other
• Contributing to achieving the goal
• Like a big family
• It's the most important asset in an open source organization.   

Issues in building a community (and solutions)

• Defining the goal(s)
  • Not everyone has the same goals, need to define them as a community
  • Each one's goal regarding the community should contribute to the community's common goal.
• How to bring people in (making it easier to get started contributing)
  • Reducing the hassles involved
  • AbiWord: Helping or mentoring the interested newbies to start contributing to a project.
  • Apache Software Foundation: give people commit access early.
  • It's version control, we can roll it back!
  • Make the restrictions social rather than mechanical (e.g., give someone commit access, but encourage them to get the code reviewed before committing, commit only in their area, etc.)
  • Use GitHub, SourceForge, or something similar to have branches and pull requests, which makes people able to commit on their branch and collaborate with the community. Also GitHub allows people to not have to learn git. [barrier reduction]
  • Have a policy that someone cannot contribute a completely new module until they have been part of the dev community for a year first.
  • One thought: maybe you don't need that many people
  • Novice issue tags plus "office hours" in IRC - mentor new dev contributors in learning the contributing processes, with an easy issue  for the newbie, so the starting barrier would be reduced.
  • Have someone who is the "greeter" in the issue queue. If an issue waits for a given time (say 3 days) with no response, the current "greeter" at least says "Thanks". This duty rotates as people get tired of it.
  • Break tasks up into manageable chunks
• Communications are a major challenge
  • Some people are always on IRC (coders usually), some never on IRC (designers).
  • Ban IRC for making decisions - has to happen on a mailing list (Apache Software Foundation and many other projects)
  • To make a mailing list work as the discussion tool, people have to be told "bring it to the mailing list"
  • Some people like asynchronous communication (e.g., mailing lists) rather than synchronous/real-time (irc), plus with a world-wide community, real-time meetings are not possible
  • Mailing lists are good for archives, but are slow for actual discussions
  • Get people together in person from time to time, if possible.
  • People are not located geographically close to each other.
  • IRC becomes active around the clock, if we have developers around the globe (AbiWord).
  • Language difficulties - English is not everyone's first language.
  • Localizers help on overcoming the language barriers to a project.
• Have to make it feasible for users to provide feedback/issues
  • Depends on the type of project, whether that is difficult or hard
  • User community is where new developers come from
  • Figure out how to interact with them
  • Derby rarely uses mailing lists - they rather use the issue tracker. 
  • Many users are more familiar with the mailing lists.
  • So mailing lists help building the community healthy and friendly.
• How to attract new members to the community
  • Marketing to attract users
    • Go to the competitive events and meet potential users there (if appropriate for project's target audience).
    • Get academics interested, then students will follow and they become part of the organization.
    • Cooperate and collaborate with the other FOSS project communities - Common code segments to be used by multiple communities.
• Statistics
  • How many contribute x number of patches
  • Measure how well the new contributors are getting integrated as regular contributors
  • Community health: are we adding new contributors
  • Don't measure lines of code or number of patches - doesn't reflect community health
  • Measure how many contributors are contributing to a project or sub-project as a measure of its health
  • Apache foundation board will warn and/or ban projects that are not on-boarding new contributors and otherwise acting in a healthy way
• 90/9/1 split
  • 90% of users do not communicate. 9% submit bugs and maybe a patch occasionally. 1% get really involved.
  • You can double the 9% part by greeting and other contributor support strategies. 
  
   P.S: The "!!!111" at the end of the title ("Community Matters!!!111") was intentional, and I put that on the session proposal too, to give it a kid's touch, who desperately wants to contribute to the FOSS communities. ;)
  
• AbiWord community's blog roll - Planet AbiSource.
  

"Verbatim" and "Reading Level" are two new cool search tools from Google. Verbatim lets us search the exact term as it is, eliminating the spelling corrections, and all the smart features of Google.

If the presentation below takes a long time to load, feel free to download it!

Google announced today the accepted students for Google Summer of Code 2011.

The students working on LibreOffice will be:

Student	Title	Mentor
Andrzej Hunt	Smartphone remote control for LibreOffice Impress	Muthu Subramanian
ArturoPL	Tooling - More and better tests	Michael Stahl
Brennan Vincent	Implementing a Microsoft Publisher import filter for LibreOffice	Valek Filippov
Daniel Bankston	Calc Performance Improvements	Kohei Yoshida
Daniel Korostil	Lightproof improvements	László Németh
Gökcen Eraslan	Signed PDF export	Stephan Bergmann
iainb	Java GUI for Libre-Office Based Android App(s)	Tor Lillqvist
Marco Cecchetti	Enhanced Impress svg export filter	Thorsten Behrens
Matúš Kukan	Telepathy for collaboration	Eike Rathke (erAck)
Rafael	New templates picking UI	Cédric Bosdonnat

Let the summer start immediately and let quality code fall like a spring rain!

This morning we learned that Facebook bought Instagram, and that Facebook paid something like 1B$. I'll skip the part where I find that this acquisition is highly overpriced, and I'll leave the speculation of who might have participated into a bidding to the analyst.

But one thing I'm sure is that they didn't buy Instagram for its revenue. What is being said is that Facebook paid 33$ per user, and quite a number of users. But what will they do with that? Simple. Monetize. And this might by the solution to my criticism of Instagram: adding a web frontend to it. A web frontend is IMHO the easiest way for Facebook to track their users. In the announcement Facebook promised to keep Instagram a separate entity, but even the owe anybody but themselves to hold that promise, they can do that and track users using a web based frontend, like all the "Like" buttons to all over the Internet. Similarly I don't see why they should remove the function to Tweet the picture. Quite the opposite, keep it, people click to view the picture, "leave" Twitter to go to that Instagram page, and voila. Checked in.

In the end, it will be a bit more like the Hotel California: you can check out anytime, but you can never leave.

If you don't like that, you can still go and request your account to be removed.

Mandatory Instagram. Deep Cove, BC.

Instagram just released the Android version of their application. Instagram allows you to take pictures with your phone, apply some filters, upload it to their service and then have user that follow you comment or favorite them. A sort of Twitter for images.

This led me to rethink why I dislike Instagram.

I dislike Instagram not because of the photographic aspect of applying random filter to random pictures to try to let them look cool, not because it is (was) an exclusive club for iOS users, users that are self entitled and angry^[1] as there are also plenty of talented people whose work I have a lot of respect for. No, it is not about that ; well it could be but that would be a very opiniated rant that would make me look like a hater. It is about the technical aspect: it is not the web.

Let's see.

If I go to the main website of Instagram, I get offered to download the app for iPhone, for Android, and beside info about them, their blog, their jobs, all I can do is edit my account. Yes you got that: it is about taking and posting picture, and from there I can't even view anything. WAT?

Now when people share their Instagram picture on twitter, you get a link like this http://instagr.am/p/JAqNexzGZr/. At that URL, you can see the picture, the comments if any, and that's it. You can not decide to start following the person even if you have an account nor can you browse through the other pictures. And to get that URL I had to "share" the image view e-mail or Twitter. There was no other way to get it.

That's exactly where my issue is. One has to use the app on your phone (previously only iPhone - even though it worked with other iOS devices including iPad) to view the pictures and the people. It is not a web application, it is Instagram. Imagine if Facebook or Twitter was like that? It is not like technology is missing. All the browsing and social features can be done as a web application, and modern browser today would allow even the editing part of the picture, and soon the taking a picture part.

And, yes I have an Instagram account, yes I have posted a few pictures from my iPad and from my Nexus One, one having a better camera than the other. Suddenly I got a surge in follower with the Android version released. But what if I wanted to use it from b2g^[2]? Even Flickr I can.

Mandatory Instagram:

I just realized that has been a long long time since I last blogged about libcdr and the CorelDraw import filter in LibreOffice. Those that know me well can imagine that it is much more fun to write code then to write blogs. Nonetheless, one serious breakthrough happened this weekend and I cannot prevent myself from climbing on the roofs and shout.

On 20^th of March 2012, Corel released a new version of CorelDraw Graphics Suite X6. We got the information from this Wikipedia page and downloaded the evaluation version on Friday. Although it was usual to see the file-format mutate a bit with every released version, this release changed the file-format substantially in what concerns the RIFF chunks. To cut the long story short, we managed to get the last pieces reverse-engineered today and we released libcdr-0.0.6 with support of all 32-bit CorelDraw formats, from version 6 to 16.

The new release tarball was integrated in LibreOffice which became the first and only FOSS application that supports versions 6, 15 and 16 of the CorelDraw file-format. This goodness will be part of our 3.6 release later this year. For those that do not know fear, the feature can be tested in daily builds that will start to appear tomorrow morning here.

I know that the distinguished readership prefers pictures to words. Here is this simple document in CorelDraw X6 format:

  

Here is the same document opened by LibreOffice Draw:

And here is the libcdr-generated SVG opened in Inkscape:

If you are tempted and think that it might be fun to participate in a reverse-engineering endavour, we have with Valek two project proposals for Google Summer of Code 2012. The first is the implementation of MS Publisher import filter for LibreOffice and the second is to help to improve and extend the Corel Draw import filter I am currently blogging about. Try to apply with LibreOffice and your life will never be the same again.

Be aware though that the application deadline is the 6^th of April and you will need to accomplish a simple programing task in order to be eligible. More details in this blog.

See part 1 if you haven't.

As of this week, some changes in b2g cause more breakage in the build process on Fedora. Plus some various bugs.

First, if when doing the make config-galaxy-s2 you get the following error:

cp: cannot create regular file `../../../vendor/samsung/c1-common/proprietary/etc/mdnie_tune_bypass_mode': No such file or directory

in the B2G directory, do a

mkdir ./glue/gonk/vendor/samsung/c1-common/proprietary/etc

and try again.

Also, make gonk will want to run a pre-build xulrunner in 32-bits

• freetype.i686
• fontconfig.i686
• alsa-lib.i686
• dbus-glib.i686
• pango.i686
• gtk2.i686
• libXt.i686

Ideally, the fix would be to actually get a 64-bits xulrunner instead. Patches welcome™ I was told. On your copious-spare-time™.

So, just before the weekend, we received the great news that Google chose LibreOffice as a mentoring organisation for Google Summer of Code again this year. Some of you might remember that last year we had several extremely successful Google Summer of Code projects and that two of our successful students are currently employed working on free and opensource software as a direct consequence of their participation in the program. I had a priviledge to mentor Eilidh McAdam and we implemented a Visio import filter that is one of the flagship features of LibreOffice 3.5. Eilidh is now employed by Lanedo.

This year, we proposed with Valek Filippov two projects related to reverse-engineered file-formats. The first is the implementation of MS Publisher import filter for LibreOffice and the second is to help to improve and extend the Corel Draw import filter that will be part of LibreOffice 3.6 release. Both projects require working knowledge of C++ and a lot of good will. Each of the import filters consists of a standalone library and a glue that plugs the library into LibreOffice. These libraries can be built as system libraries and LibreOffice can use them from the system. The advantage of this approach for a student participating at the development is that there is only a minimum need of recompiling LibreOffice if some substantial part of the glue (that is rather small) changes. Therefore, I encourage all of you who are considering applying with LibreOffice for this year's Google Summer of Code to have a close look at those two projects. As a bonus is that if you are successful, you become famous and eventually rich.

You can have a look at libcdr, the horsepower behind the Corel Draw import filter and at the skeleton of libmspub, that will be the basis of the Publisher import filter. And don't hesitate to become rich and famous with Google Summer of Code at LibreOffice

• Google Summer of Code is all about being Open Source.
• Get your basics and motives right.
• Netiquettes.
• Community Matters!!!111
• Sign up to the lists.
• Join the relevant channel(s).

Technologies

• Version Control Systems
• SVN, CVS, GIT, Mercurial, ..
• Build Tools
• Ant, Maven, ..
• IDEs (Integrated Development Environments)
• IntelliJ IDEA, Eclipse, ..
• Microsoft Visual Studio, Anjuta, ..
• Issue Tracker
• Bugzilla, Jira, Trac, ..

Communicating with the team..
.. and the mentor, over the Internet..

• Mailing Lists
• Dev, User, Commit lists, sub-groups, ..
• Internet Relay Chat (IRC)
• Issue Tracker
• Forums and wiki
• Blogs
• Skype, Personal Mails, gtalk, conference calls, .. [with the mentors, if that is preferred.]

Network Etiquettes

• Be Specific and clear.
• Research (google.. ;)) before asking.
• Be helpful to others.
• Be ethical; respect.
• NO CAPS! (UNLESS YOU ARE SHOUTING!)
• Don't take messages personally.
• Dn't snd ur sms msgs to thrds or lsts.

Proper Addressing..over the lists/irc/..

• Address the devs and users properly.
• First Name or Preferred calling name.
• NO Sir, Madam, bro, sis, pal..
• Even if you know them, personally.
• No Mr., Dr., or Prof. either.
• Be gender neutral.
• “Folks” over “Guys and Girls”.
• Not too personal.
• Use “Hi”, instead of “Dear”.

Mailing lists

• Post only to the relevant list.
• Check the mail archives first.
• To avoid getting RTFW/RTFM responses.
• Avoid HTML mails.
• Most of the mail servers do not like it. For eg, all the html mails posted to abiword mailing lists are dropped by the mail server. Make sure to turn off the html or rich text mail feature in your email program. It is by default HTML/RTF mail in the web mail like Gmail/Yahoo. Make them send plain text email.
• No [URGENT]/[IMPORTANT] tags.
• No unnecessary attachments.
• No Cross Posting.
• Stick to the proper mailing list only.
• Don't hijack threads.
• Don't post off-topic.

IRC Etiquettes

• Be an observer first.
• Refer to others using their irc nick.
• Whenever my irc nick is mentioned, I get a pop up message from my irc client such as pidgin.
• Don't expect immediate replies; wait.
• Don't post bulk of text into irc.
• Post error logs to http://pastebin.com/ or http://paste.ubuntu.com/ and share the url instead.
• Avoid these common mistakes.

Find a mentoring organization..

• Have a look at the list of GSoC2011.
• Since the list of this year hasn't been selected yet.
• 175 Last year!
• New Organizations.
• Google as the mentoring organization.
• Introduce GSoC to an organization (Sounds Smart!).

Find THE right project..    

Get to know more about the projects

• Talk to the mentor(s) Assigned by the organization for each project idea.
• Mailing lists and archives.
• Issue Tracker
• Open issues or tickets
• New features/enhancements (RFE)
• Bugs (easy/difficult and normal/critical)

What makes you special?

• Experience
• Being a great user doesn't mean that you can be a good developer.
• Your interests and motivation
• Pick something you really enjoy doing.
• Being a great developer doesn't mean that you can be a good contributor.
• Opportunities
• What makes you the right person?
• Willingness to contribute to the community beyond the time frame of GSoC.
• We want committers and long time volunteers - Not just students!

Experience

• Languages
• Java, C++, C, ..
• Not much time to learn a new language (?)
• Prove It!
• Patches.
• Assist other students!!!
• Project expertise
• Bug reports and fixes.
• Go through the archives, wikis, and web sites.

Opportunities..

• Project that matches your previous work experience.
• Choose the right project.
• Timezone Difference 
• Use it effectively - Most of us prefer to work in nights too, as we have the lectures in the mornings.
• Multiple Applications (20!)
• Preferences! 
• Communicate early and often.
• Be heard, visible, responsive,  and quick!
• Ask questions, and more importantly answer others' questions.

Apply


How to impress the mentors/developers?

• Stick to the organization's template.
• AbiWord's Application Template.
• Abstract.
• Introduce yourself properly.
• Focus on the relevant facts.
• Why do you fit? Your skill sets.
• List of the patches (if any) you have submitted.
• Project Goals
• Proves you got them correct.
• Deliverables
• Code, Documentation, test cases, ..
• Description - can also be given along with the timeline
• Benefits to the organization and other projects  
• Timeline
• Finer details - Break upto periods of 3 - 4 days.
• Testing takes time - Don't be over-optimistic.
• Some organizations require considerable work hrs/week (40 ?).
• Links - References and additional details.

After the submission..

• Don't go invisible!
• Evaluation is still going on.. ;)
• You may be asked to provide additional information.
• Patches.
• Screenshots.
• Start coding on your project - only if you didn't apply for multiple projects.
• Be motivated.

Got Selected? Community Bonding Period!!!




A few links

• Google Open Source Blog on GSoC 
• GSoC Student Guide
• GSoC-2011 FAQ
• GSoC-2011 Accepted Organizations
• Proposal [Pradeeban] - GSoC 2009 AbiWord
• Proposal [Pradeeban] - GSoC 2010 OMII-UK/OGSA-DAI

This blog post has gone a bit longer, since I tried to include all the information in a single post. Wish you all the best.

Yesterday I tried and successfully built b2g on Fedora 16 x86_64, targeting the emulator. These are my notes on how to do it as the instructions to setup the build environment are very Ubuntu centric.

The prebuilt binaries expect to be on a 32-bits system. So we are gonna need to install 32-bits packages. Also there is a requirement to have adb to boostrap (it is built afterwards). Fortunately you can skip installing the SDK for the bootstrap and use the Fedora package android-tools that provides adb.

The packages you need, that will also pull the proper dependencies are:

• glibc.i686
• glibc-devel.i686
• libstdc++.i686
• ncurses-devel.i686
• readline-devel.i686
• zlib-devel.i686

To run qemu:

• libXrandr.i686

You also need the usual requirements to build Firefox as well as git. Install these using yum.

Then follow the build instructions to build on QEMU.

Enjoy !

(dont forget part 2)

What is it with airline (and governments) making air travel inconvenient? I don't travel much compared to some other people I know (never got elite status on any airline, and barely got enough miles to get a cheap flight to France), and I never encountered serious issues when flying. But still.

Luggage

Over the last few years a new extortion scheme has appeared: luggage check-in fees. Yes you read it: the airline have decided to charge you a fee to check luggage in. What I don't get is why do they charge you for the inconvenience, which benefit them as with less luggage in cabin they have a more streamlined boarding and de-boarding. That I don't get it. This was started with US based airlines to supposedly compensate for their loss of revenue (it got worse after that), and because Air Canada innovates in air travel, they followed suit. Also the policy being inconsistent, code sharing and other stuff make things even more confusing.

Now I plan cabin luggage only. Not always easy, but utterly more convenient and there is no risk to get the suitcase lost (hello Air Canada) or damaged (hello Air France). I end up being able to bring more gear and inconvenience the airlines even more. I get to learn to pack light.

Food and beverage

Not only you now get charged for food in North America on flights (including long one) but airports are inconvenient to bring your own food or get food (not even asking quality at that point). Case in point, my flight to Toronto from Vancouver left from gate C51 in Vancouver. There, there is no food. You have to walk through the whole terminal to get something. And I have seen other instance of that in other airports. Not mentioning the security theater that decided that carrying a bottle of water was dangerous.

Security theater

Simple put I always go through the metal detector in the same "uniform". And 33% of the time (whichever airport, it is not even dependent on the checkpoint) I get to have the machine beep because of my belt. They probably don't get to recalibrate the machines often which does not inspire confidence in them operating the X-Ray body scanner.

Nickel and diming

If you are tall like me, you have to suck it up or pay. No more emergency exit row, front row and so on. Yep, they charge you for legroom: Air Canada used to be nice with that and Air France being dicks. Now they are just equal opportunities. I'm sure airlines would charge extra for accessibility if they legally could, like they have try to do for overweight people.

The only thing I get is Air Canada charging 3$ for the headphones. Bring your own, that's fair, as they are standard.

Last week I was in sunny San Diego, CA at the 27th CSUN accessibility conference, part of the Mozilla delegation along with Eitan and Marco. So was a very enlightening event. I'm quite new to accessibility technology and what I saw is an even greater reliance on technologies, for the good and the better.

Beside the usual important work on web accessibility, there was also in multiple occasions discussions about repurposing tools for accessibility need. One concrete example is Google Goggles. This app for Android always seemed to me to be a gadget, but in fact it has proven to be a pretty convenient tools for things like reading bank notes (the US dollar notes don't have braille, unlike the Canadian one). Or face detection in a cell phone camera to take a picture: the framing guided by voice.

Another use was Google own Google+ hangout^[1]. Google hangout is for live conversation using sign language. There is in fact a lot of work done to make the video fluid and good enough for that. Video fluidity was also an argument presented by the Apple marketing manager when talking about iOS and FaceTime. Some fantastic stuff.

Android accessibility is a different story. It seems that there is a large difference between 2.3 and 4.0 in term of support, where 4.0 (Ice Cream Sandwich) is going way further. One of the major change is that now accessibility is required for the Android Google Marketplace lock-in. No more stripped down like it was on the Asus Transformer running 3.2. It is unclear however if the skinning that Samsung Touchwiz or HTC Sense UI will be required to be accessible: as it is now, HTC Sense UI actually is forcing to root the phone and have Cyanogen Mod installed in order to be accessible. Also I had a chance to see Eitan's work in Firefox for Android accessibility.

Things I saw: a demo of Windows 8 on a tablet with IE 10. They have accessibility built into with touch discovery and gesture, and video subtitle and captions. I also happen to have tried for the first time a Windows Phone 7 phone and saw a second one on the plane (bound to SEA). iOS devices seems to dominate and the reason is that their approach to accessibility from the ground up is probably the best on the market for non market-specific devices. And they also support bluetooth Braille readers.

It was good to meet with everybody, Ryan, Jenisson, Laura, Kevin, Sina, Victor, Carol, Matt, Richard, Matt, Eitan, Marco, Rainer, Steven, Henny, Denis, Sylvain, Arnaud, TV, Naomi, James, Alice and the rest of the Google team, and many other fantastic people I possibly forget.

I felt so much energy in that conference. So many good things happening. So many to come.

In short, I now have a Nokia n9, and setup a scratchbox for it, and compiled & installed abiword, clawmotia, unison, and libferris for and on the device. If that didn't enlarge your page down key, the longer version now follows ;-)

FWIW my impression of the device is very positive. Hardware wise the biggest issue I have is the inability to add more storage to it. A high gb microsd slotted in would make things a whole bunch nicer, mainly for using the device as a music box on the road. The speed of interaction is very nice, and the swipe interface is very easy to get used to. Just flick an app away to minimize it or flick from another screen edge to close it.

gstreamer works quite nicely for viewing network streams, though there is a deadzone bar on the logical "bottom" of the screen (left of screen in portrait mode). I noticed this bar in abiword too, so I assume it is an issue with going fullscreen for non Qt native apps.

There isn't much to show for unison, as I tend to drive that from the dekstop/laptop end of the connection. Getting it on the device is always a matter for first compiling ocaml and installing that into the scratchbox.

One very pleasant surprise is how snappy clawmotia runs on the n9. Startup time is significantly less than on the n900 and the screen operations like swiping the main controls left to get to the jog shuttle page is now at an acceptably smooth speed. I'll have to work up a video of this in action to show the speed of things...



I got libferris compiled for the n9 too. Using boost::spirit for some of the parsers has dropped one compile time dependency away. I did make both ferris and ferriscreate able to compile in glib2 only mode. You loose one or two apps by doing this, but it also makes the footprint smaller so that I can use it with QML apps without needing to pull in gtk2 from a third party repo just for those apps in ferris itself. Mainly some capplets, gfcreate, and the gfcp and other graphical coreutils reimplementations are lost in building this way.

And what is not complete without a screenshot of things on the device? Sorry for the quality of the picture, I need to work out lighting for some device shots a bit better than this adhoc quick shot. Just to tap into the ferris power a tiny bit I decided to mount an XML file as a filesystem and fcat directly into it.. A few of the fun things I plan are a QML client for index/search using the customized maemo index backend in libferris and using the mounted pulseaudio and mounted gstreamer to implement yet another audio player for the device. The index+search in both these apps should be blisteringly fast, given that I could index an NFS mount with 10x the data I could hold on an n810 and search as you type in real time...



Abiword proved to be the harder thing to compile for the n9. It seems GTK2/3 has fallen off the device so I got gtk2 from a third party repository. The downside is that the app doesn't run entirely fullscreen and has pretty much no finger friendlyness from gtk2 itself. Oh yeah, the virtual keyboard doesn't come up on text entries in gtk2 either. I might be compiling and installing gtk2 incorrectly on the device, so this complaint about device interaction might be my own fault?

I then got libwv and libwmf, following the dependency rabbit down the white hole. Of course my abiword compile has full ODF support in it too! The below screenshot is of one of my sample ODF+RDF documents with the content that links to RDF shown in purple. For more info on RDF in abiword see the abiword talk video from lca 2012.



More fun an games to follow, and I'll post a link to a repo with the debs once I work out where I'm going to host the 100mb odd of files. Not all those are for the device, some are mainly for scratchbox such as the dev packages and full ocaml compiler debs.

A while back, Jaisen Mathai decided to start OpenPhoto, a project dedicated to provide a Free Software hosting solution for photos, to liberate the users from the claws of hosting services like Flickr, Picasa, etc.

This is an idea I have been mulling for a long time, so much that I even started on my own, but it didn't go very far. So when I found out about OpenPhoto, my curiosity got picked. It seemed to fullfill the same goals so I decided instead to look at it.

My first task was to get it to run. The catch is that from the start it was designed to run off Amazon Web Service and their SimpleDB. Not something I wanted. So I started writing the needed code to support MySQL and local filesystem to store the photos. And that's how it started. Then I implemented support for importing metadata from the pictures, automatically, something that I have seen missing in several of the competing services.

The OpenPhoto project is part of WebFWD, Mozilla's Open Innovation program. And it was one of the first project to make use of Mozilla's excellent BrowserID.

The source code is available on github. Feel free to download it, install it, tinker with it. Pull requests are more than welcome. If you don't feel like installing it, you can still go to openphoto.me for the hosted version.

And since I like "dogfooding", I'm running my own instance.

tl;dr we need a Gnome computer.

This is not about choice, it is about freedom.

A hardware platform that would be libre, that would run a libre OS, based on Gnome, Linux and GNU.

A hardware platform whose software stack would be vertically integrated for a maximum user experience: working out of the box, as advertised.

And for those who think it is about choice, think again. Choice is dealing with a bazillion different hardware configuration, drivers, etc. Dealing with more poorly written drivers (usually from hardware vendors) or proprietary (hello GPU driver) or even buggy firmware.

Next will come the portable devices: tablet, phones, etc.

You might still remember some of my blogs about our new and shiny MS Visio import filter in the upcoming LibreOffice 3.5.0.

But what about 3.6.0? Is it going to be an exciting version too? Well, the answer depends on what kind of things excite you generally, but for sure, there will be a lot of goodness as usual to make the best free office suite even better.

In my free time, I have been working for some time already on the next graphics import filter for LibreOffice. This time it will be a CorelDraw import filter. The horse-power is a library, libcdr. In the same way as libvisio, libcdr reuses the API of libwpg and thus is easily pluggable into LibreOffice reusing all the ODG generator classes of the current writerperfect module. The importer is currently part of the git master tree.

You might be already shouting: "Where are the screenshots?" I know that a picture speaks louder then hundred words, and so here you are served:

Simple and more complex shapes in CorelDraw 7

The same shapes imported into LibreOffice Draw.

As you can see, it is an initial implementation, which cannot but get better. If you want to participate in this adventure, you can drop around at our IRC channel #libreoffice-dev channel at irc.freenode.net where a community of smart and friendly developers can direct you.

Stay tuned for more nice pictures as this project advances.

FOSDEM 2012 is just round the corner and, as you might know, LibreOffice will have a DevRoom this year too. And, as it was already publicized, your servant and Eilidh McAdam of libvisio fame will attend too. The goal of this event will be to help you to become a LibreOffice developer, by helping you to get your first contact with the code from inside.

How to prepare for the event?

In order to give as many community members the possibility to speak, the presentations will not take more then 15 minutes each. But we will be there for one-to-one contacts and hacking goodness. If you are interested in contributing to our new Visio import filter, or the upcomming Corel Draw and MS Publisher filters, here is what you can do:

1. Find a bug that is bothering you in the current Visio import filter, or some simple feature that the importer currently does not support
2. Check out the following libraries:
   • master branch of libwpd (git clone git://libwpd.git.sourceforge.net/gitroot/libwpd/libwpd)
   • STABLE-0-2-0 branch of libwpg (git clone -b STABLE-0-2-0 git://libwpg.git.sourceforge.net/gitroot/libwpg/libwpg)
   • master branch of libwps (git clone git://libwps.git.sourceforge.net/gitroot/libwps/libwps)
   • master branch of libvisio (git clone git://anongit.freedesktop.org/libreoffice/contrib/libvisio), and
   • master branch of libcdr (git clone git://anongit.freedesktop.org/libreoffice/libcdr)
3. Build them as system libraries and install them in the same order.
4. Then build LibreOffice according to these instructions. The important thing is to use those system libraries that you just built. To do so, be sure you added to the configure flags
   • --with-system-libwpd
   • --with-system-libwpg
   • --with-system-libwps
   • --with-system-libvisio
   • --with-system-libcdr

With this kind of build, you will be ready to make the most from your Brussels weekend. Nevetheless, you can drop around at our IRC channel #libreoffice-dev channel at irc.freenode.net for more information and ideas.

Starting to do it instead of planning to do it ...

... is the best way to enter the FOSS development. That is why your servant and Eilidh will be around to hold your hand with debugging and finding way to implement your favourite features. We will answer your questions about the library design. We will point you to the place in the code where your bug might linger. And for more complicated stuff, we will debug it with you.

Don't expect us to give you a fish, but we will certainly teach you how to catch it by yourself. And in the same token, you will become a contributor inside a community of smart people that is fun to hang and hack with.

See you in Brussels the 4^th and 5^th of February 2012.

Since I joined the accessibility team at Mozilla I took on one of the task that was in need to be solved: bringing back accessibility in Firefox on Mac as it has been lagging behind.

Marco already wrote about how things are ramping up and started filing more bugs on what is broken in the build I provided.

With the quick release cycle, I can't really commit on which Firefox version this will be in, but the code is current in Nightly, aka Firefox 12, except that on Mac we don't build with accessibility enabled yet.

Abiword now has growing GUI support for editing RDF in ODF documents. Much of this support compliments what is available in Calligra for RDF handling. There are some areas where Calligra has more features and some areas where Abiword now does. Hopefully both will continue to have a large and growing shared feature base.

As some folks will know, ODF allows one or more RDF/XML files to be shipped in the ODF file, and for that RDF to be linking to the document content from the content.xml file. This means that you can explicitly say that a 1/2 inch bolt is from a particular maker and was procured on the 3rd of January 2012 by going to their office at geolocation ?x. Handy when you are reading the document a year down the line and want to know which office you bought the bolt from and the exact length of its thread.

Looking at the below image, one can see the purple underlined pieces of text. Each of these has some RDF associated with it. The citation to Dan Brickley has both contact and location RDF associated with it. Looking at the toolbar, towards the right side you see an "R" to start a change tracked document, and the "RF" button. Sorry about the images there, I draw at the 3 year old level so my icons are not quite polished shall we say. Anyway, the "RF" button selects this reference to an RDF item. So if you are between the "am" in the purple "James" then the whole word will be selected with this button. The ">" and "" buttons then allow you to move to the next and previous reference to the selected RDF item. As you notice another purple James later in the document, this is the second and only other reference to him and you can move between them using these buttons.



These purple links I call "RDF links", which is a bit of a play on hyperlinks or bookmarks. Behind the scenes they are implemented using xml:id values and pkg:idrefs to those from RDF.

A feature added in the last days is the ability to capture and navigate by the relation between two RDF links. This is currently done by selecting a "source" link and then clicking another rdf link and setting the relation to the source. So in the below screenshot I am saying that Mark foaf:knows James. You will also notice the "Find by Relation" option which I can then use to see the people that mark foaf:knows. In the spirit of the foaf definition, I have made this a symmetric relation. So there is no stalking, or "following", if James knows Mark then Mark knows James. Asymmetric relationships are also possible, like son, child, or contains. I am hoping to add this feature to Calligra too in the future as the relations between RDF objects is one of the more powerful features that can be offered by using RDF in a document.



Note that the prev/next RDF item buttons work with relations. If I pick mark and navigate to the James he knows then I can "next" from that james to select the second reference to James. This is one recurring theme to RDF in ODF, that RDF objects like contacts can be cited or linked zero or more times in the text content of the document.

As mentioned above, the converse is also true, and the Dan Brickley text has two logical RDF objects linked to it; Dan's contact information and his location. Handling this multi-object for a single site is a little tricky and in this editing will create a window with both the semantic objects in it to let you edit the RDF abiword knows about. Note that this dialog is actually backed by two (or more) SPARQL queries;



If you are not squeamish about your triples then the "Show RDF" option for an RDF link will let you get right at them and edit away as shown below. There are a few technically cool things about this dialog: firstly the "Restrict to RDF Link" combo box lets you select one or more RDF links that the triples will have to be associated with, and secondly abiword makes sure any edits you make are properly linked to the RDF link you right clicked on. What I mean by this last bit is if you right click the RDF link "alice33" add a new triple "uri:alive myvocab:likes uri:bob" then abiword will add the triple "uri:alice pkg:idref alice33" for you. This is sort of having abiword do what you mean in that you want the new triple to be associated with the link but don't necessarily want to have to explicitly say it all the time. By choosing to edit the RDF for the link you have already explicitly said once that you want these things to be linked. This also applies if you change a subject, uri:alice to uri:amanda will update the pkg:idref values for you. Keep it linked, keep it valid.



Going one level deeper, the above dialog is actually a subclass of a restricted RDF model created using SPARQL. The SPARQL model is read only, and the subclass, RDFModel_XMLIDLimited handles mutations by creating a wrapper object which takes care of the automatic triple relinking mentioned above. Those still awake might like to see the abiword trunk code for src/text/ptbl/xp/pd_DocumentRDF.cpp.

This is part of an ongoing mad hacking sprint that is leading up to a talk at LCA 2012 which starts in a week. Many of the things I mention here are not in trunk yet, and only tested on Linux/GTK+3. Those in Ballarat in a week might like to pop in to the talk given my Martin and myself on Friday the 20th.