Idén is volt Balaton Maraton (a tizenhatodik, nekem a negyedik), sikerült idén is teljesíteni a szintidőt, sőt… de ne szaladjunk ennyire előre.

mso-dumper is a project that creates some — more or less human-readable — dump from binary files. Initially Kohei Yoshida developed it to dump XLS, then Thorsten Behrens added support for PPT files, finally during last November I started to add DOC support.

You may ask: why that is useful? My answer is that I spend quite some time on the import/export filters of LibreOffice Writer, and to be able to improve or fix such filters, some knowledge of the file format in question and Writer internals is needed. Regarding the file format knowledge, I find it much easier to read the specification once and implement some simple dumper based on that — than reading the specification again and again, and just trying to understand what’s going on inside a binary file using a hex editor.

To my knowledge, such a dumper for the DOC format (in particular the WW8 version of it) did not exist previously. WW8Dumper was the closest match, but that was far from complete and I found extending mso-dumper easier.

To stress-test the parser, I used get-bugzilla-attachments-by-mimetype to get all DOC attachements from the Freedesktop bugzilla, and during the last days I fixed the remaining crashes (actually this is why I write this post now ;-) ). If you want to try it out you can do so by:

The idea is that on any input the dumper should not crash: instead either it should give you usable result, or in case some unhandled structure is reached, it should print a <todo> XML tag. Other than that, of course patches welcome — that said, Maxime de Roucy already contributed a patch to the DOC part of mso-dumper, thanks! :-)

A hétvégen Pécsett jártunk. Javában zajlott a Zsolnay Fesztivál, így talán az átlagosnál több ember hemzsegett az utcákon, de nem volt nyomasztó tömeg így sem. A következő helyeket érintettük:

Szombat:

Vasárnap:

Hétfő:

Szállásunk a Corso Hotel volt, akik egyből adtak egy Irány Pécs! kártyát, valamint náluk vettük meg a fenti fesztiválra is a napi belépőt, ezek után már a legtöbb helyre ingyenesen bejuthattunk.

Képek erre.

Last week was Hackweek at SUSE — below is a quick summary on what experiments did I do during that timeframe.

Múlt vasárnap (fehérvasárnap) bringázni voltunk a Pilisben. Nem mondom, hogy a végére nem fáradtam el, ez volt idén az első alkalom, hogy 100km feletti túrára mentem — de már bőven ideje volt.

A GPS track mutatja, hogy mi Budapestről mentünk, a társaság másik fele pedig Szentendréig HÉV-vel, és ott csatlakoztak hozzánk. Onnantól pedig a Dömör-kapu, Pilismarót, Két-bükkfa-nyereg, Dobogókő útvonalat követtük.

A kmóra a következőket mérte:

A túrán használtam először hosszútávon a nyári (nem havas, stb) időkre szánt Schwalbe Silento külsőket, egyelőre meg vagyok velük elégedve.

If you ever tried to use graphical bullets in Writer (Format → Bullets and Numbering → Graphics), you may have noticed that only the ODF filter can load and save such a numbering. This is now improved a lot. Motivated by seeing this is now handled in the binary DOC filter, I now added support for this also to the DOCX and RTF import and export filters. If you want to play with this feature, core.git also contains a DOCX and an RTF sample as well.

LibreOffice started to use Gerrit for code review, and while occasional contributors can submit patches manually, in case one does many reviews, it’s handy to use a dedicated tool. In core.git, we have logerrit, but that’s not advised for regular reviewers, either, git-review is recommended instead.

So I looked into git-review. The good news is that it’s packaged already for most distributions, e.g. a simple

on openSUSE installs it.

I wanted to use this tool for two tasks:

Probably the browser interface is still the best to comment (especially inline comment) and approve changes, though David even submitted a proof of concept patch for that as well.

Finally, let me just clear two myths:

When you create a rectangle or text frame in Writer, you have two choices. You can use the draw toolbar to create a drawinglayer rectangle, and you can also insert a text frame. The drawinglayer shapes are shared between the LibreOffice applications, and already supported having not only a bitmap or a color but a gradient or a hatch as a background. The benefit of Writer text frames is that they can contain anything a normal Writer document can — think of columns, tables, etc. These features are not supported by drawinglayer rectangles.

So till now you had to decide what to pick, but it wasn’t possible to have both. LibreOffice 4.1 makes this situation better. Now it’s possible to have gradient backgrounds in Writer text frames as well:

The nice thing is that this feature was already supported by ODF, just not by Writer, so no such paperwork was needed this time. Also the OOXML filters are updated. As I already stated in this comment, the binary DOC and RTF filters are not yet touched regarding this feature — though I already looked into the RTF one, and have some idea what rework is needed there first.

We spent the last weekend in Brussels, at FOSDEM 2013. Outside attending great talks, I most enjoyed meeting people I haven’t met in person before, in no particual order:

Also fixed fdo#48440, fdo#58646 and fdo#59419 during less-interesting talks. ;-)

Additionally, during the last day we had time for some site-seeing, some pictures are here. Slides of other LibreOffice talks are also available.

There are multiple strategies how to add testcases for code that sort of works, but has no or too few tests. One approach (that works quite well in LibreOffice, for example) is to just add tests for new code, and there the test is "good", if it passes, but it fails if you revert the corresponding real change.

An other approach to avoid duplicated tests is to use a tool like lcov, that can perform line or function coverage analysis for you, so a test is "good" if it increases the coverage. I wanted to look into this later approach for LibreOffice, but I decided it’s more fun to try this out for a smaller project first. That’s when adding testcases for BitlBee’s Skype plugin came into my mind.

The problem there is that manual testing typically includes multiple online Skype clients and an IRC client as well, and such tests are extremely unreliable. So I thought: if I’m able to mock both the interactive IRC and Skype clients, then it’ll be easy to test the C Skype plugin itself, even for very special scenarios (like changing a groupchat topic in the middle of inviting somebody to a groupchat or similar).

So here is the result looks like:

For skyped, the exact traffic is recorded and played back later; for BitlBee, only the outgoing traffic is exact, for the incoming traffic pyexpect allows just patterns (to allow tolerance for not interesting changes). Once the framework was available, it was quite easy to add testcases: I already have 70%+ coverage, and I think approaching the 100% function coverage is realistic. :-)

What was also interesting is that it turned out the latest upstream lcov release is not compatible with gcc-4.7, but the necessary patches are now integrated, and the next upstream release will work out of the box.

The BitlBee mock files can be found here. Given that there are now instructions to do similar analysis for LibreOffice as well, I hope to look into increasing test coverage for the classes I maintain as well.