CellarDoor in German plus Debian package

Dear friends

Some quick updates on CellarDoor are due. Since last week, it has debian packaging support in the buildsystem, contributed by Milton Soares.

Simply run ‘make deb’ and you are set: a nice debian package is generated at end.

Next, Adriano Cavalcanti contributed another translation to CellarDoor, German:

Thanks to the fact that German has some bigger than average words, it will require some adjustment in some parts of the UI, but so far so good! As soon I finish some missing features, I’m planning to make a ‘non-hackers’ release.

Currently CellarDoor is available in:

• English
• Brazilian Portuguese
• Italian
• German

Do you known French or Spanish?

CellarDoor got its second translation: Italian!

Friends

Just 1 day after blogging about my pet project CellarDoor, I was contacted by Francesco Frassinelli asking about how to make translations.

The result in the next day can be checked below:

Of course there are some places in the UI that we will need to make minor adjustments, but it certainly is progressing really fast (except for minor UI code glitches, the Italian translation is done).

Do you speak German or French? Want to contribute to OSS/Freesoftware? Let me known.

Presenting CellarDoor

Last January I was talking with my friend Wilson Prata about applications. We have partnered a couple of years ago when creating amora (which by the way needs some care urgently, but this is another matter) and he presented to me a concept for a nice and cool new app: CellarDoor.

What is CellaDoor? Well, it is a wine app. Have you ever started a conversation with someone that also appreciate wines and then failed when trying to remember the name of a good wine you tasted a couple of months ago?

Or what about easily exchanging a wine recommendation? Trying to keep notes in a restaurant napkin is not really much effective.

Trying to address this and other user cases, I started to work in the mockups that he had at time. A great UX designer once taught me the value of close cooperation between programmers X designers to create something that looks good and performs well (and I honestly believe that the best way to create an app is to have at least one designer aboard since the very beginning). This is a different approach than the traditional hack-hack-hack then later ask a designer for some cute icons which is, with some exceptions, the rule in OSS/Freesoftware world.

Unfortunately, I lacked enough free time to progress quickly, but I believe that the app has progressed well enough for a public release. You can checkout the project’s webpage.

So, what are the current features? Here they are:

• good looking UI with nice usability
• create a wine card with basic information (year, name, vineyard, etc)
• filter by wine type (e.g. red, white, other)
• persistence of data in a sqlite database (which by the way you can edit in the desktop)
• Supported platforms: Linux, OSX, Windows 7, Symbian 5th and 3 (e.g N8, N5800, etc)
• snap a photo of the bottle/cork in supported platforms (Linux, Symbian). Persistence of this photo is my todo list (hey, I didn’t say that the app is completely done!).

How it looks like? Check it (running in OSX 10.6):

== What about the technology? ==

The magic to support such varying OSes (Linux, Window, OSX, Symbian), form factors (Mobile, Netbook, Desktop) and resolutions (from 360×640, ranging in 1024×800 and up) is that I used Qt/QML for the UI. At time that I started, Qt Components were not ready yet, so I got to implement my own (probably buggy) widgets like a combobox (based in joint work with my other friend Ricardo Sato) and a calendar widget (coded together with my friend Igor Trindade), this last widget deserves to be pictured bellow:

== What is next? ==

A long backlog indeed waits in the issue tracker of the project. Between those, I believe that next steps should be:

• Packaging: for symbian I have it done (self signed), Window7 I played with WiX to create an installer but I need help for testing. OSX packaging (.dmg) and rpm/deb help would be greatly appreciated;
• Translation: it currently supports English and Brazilian Portuguese. I believe it would be cool to support other languages (French, Italian, German);
• Coding: there are several features that would be awesome to have, if you are interested, let me known.

So, since ATM there aren’t public packages yet, I guess this is a ‘hacker’s only release’. What you need to compile it is Qt 4.7.x and if in Linux, Qt Mobility 1.1.

Concerning the license, it is good and old GPL v2 code with CC non-commercial for the artwork.

Long time no see you

It is being almost one year without posting in my blog… What else to say, besides I have being busy? Since my last post, I have:

a) Trying to be a not so lousy father;

b) Led 2 teams in 2 different projects at same time at OpenBossa (both non-oss, targeting Symbian and Maemo respectively);

c) Visited Boston, Brussels, Miami, London,  Bristol, Jericoacoara;

d) Improving my old motorcycle with new accessories;

e) Bought a Brazilian off road “car” and travelled through the country side;

f) Moved to a new apartment, with space for a small office;

g) Since just motorcycling is not enough, tried some new things:

h) After learning QML, decided to write a new pet project (details in the next post!)

i) Reviewing and merging several patches in libgcal (news soon!)

And probably some other stuff that I plainly forgot. Now, I’m planning to post once in a while to not let my blog to collect dust… after all, like I said way back in September 2009: “… having a half-alive, half-dead, zoombie-like blog is worst than having no blog at all.”.

Amora: 14001 downloads

Around 2 years ago, I did the release of Amora (A mobile remote assistant) for Nokia smartphones. This started as a pet project, mostly driven by my own requirements to have a good software for reliably controlling slides and movies using my cellphone through bluetooth. It has a server part, installed in the desktop (written in ANSI C) and a client part, installed in the cellphone (written in Python for S60).

Recently, I haven’t being really active developing it, mostly thanks to some factors:

• At the time, I was waiting for PyS60 2.0 being released (and it took a long time to finally being made public);
• This is my perception, but I feel that there is a shift from python to javascript as a scripting language in general;
• I have being waiting for Qt in Symbian starting to support some features required (like bluetooth, for example). There is a QBluetooth project, but it requires some special capabilities to even install in a real device (and AFAICT, there is not an official build of it for third-party developers to use, say like Qt mobility);
• Finally, I have being quite busy with other projects.

Last week, while checking the project’s webpage, I noticed this:

Not too bad, hum? If you consider that from all the demographics, it targets only the Nokia, smartphone users (3rd and 2nd edition), non-touch, that runs linux as desktop (i.e. a subset of a subset of a subset of…). There is the added complication that the client is also available in other websites for download, so this number probably is not that accurate.

I guess that the fact that it followed the Unix philosophy (“do one thing, do it well”) and the great artwork (provided by my friend Wilson Prata and Alexis Younes) helped. And the fact that it is included in several Linux distros too! Special thanks to all the pacman (package mantainer) who packaged amora.

ps: initially, I thought about naming this post “Amora: 14k downloads”, but that would be incorrect, since 14k == 14336.

libgcal 0.9.6 plus akonadi resources 1.2

Dear friends

It is being almost 3 months since the last public release of both the library and the resources. In the library, no new features on this release, but some improvements and bug fixes. The laundry list goes:

• restored ABI (as noted by Fathi Boudra, gcal_contact_get_im was missing after the work in supporting multiple im fields)
• CMake and autotools buildsystem will install the library in INCLUDE_DIR/libgcal (as per request of Mario Ceresa so it will adhere to Fedora Core packaging policies). Autotools patch by Ademar Reis.
• And a new cleanup function gcal_final_cleanup() to avoid a potentially crash scenario if libgcal is linked with something else that *also* uses libxml. Nice patch by Chris Frey (thanks a lot dude!).

But for the resources, some nice new features:

• IM fields are supported (as a matter of fact, this feature was available in libgcal since 0.9.5 release, but it never made into the akonadi contacts resource). Patch by Holger Kral.
• Fix a scenario were authentication would fail if both resources (gcalendar + contacts) are set while using different google accounts. Now user information is saved in KWallet per resource (and the key also relies on the username), this makes possible the next new feature.
• Multiple users are supported as long you have 1 resource per user. Previously, that would not be possible, because I was saving a single entry in KWallet (so it was overwritten after each new resource inclusion). I have tested with 3 different users *at same time* each one with both resources (contacts and calendar, total 6 resources instances) and its feeling quite stable.
• Fix in authentication dialog, now the configure message reads “Your Google mail username (or user@whaveter.domain.com)”. I received some many bug reports about this, mostly because the previous message didn’t clue the user that hosted accounts are also supported. I’m just not sure if the translation strings were updated…

So, if you are curious, download it from the libgcal project website and have a try (compiling instructions are available in the tarballs). Or wait a couple of months and it should be pre-packaged for you in your distribution.

Known issues:

• Only the main calendar is synced… supporting multiple calendars within the same account is in my to-do list.
• Please, only 1 resource type X 1 user account. I haven’t tested the non sense case of adding more than 1 resource instance type per user account (so you are on your own if you do this).

Sliderlayout

It all started with a simple problem: I want to change from one list of things to another, doing a ‘slider’ like transition (like you would do for example in a music player when you choose an artist and go to another list with the tracks).

That sounds pretty simple, right? Just fire a QPropertyAnimation (or if you are using Plasma, a SliderAnimation is even better) and animate the position of 2 widgets.

But what if I want to have those widgets inside of a layout (e.g. QGraphicsLinearLayout)? After all, I want my UI to scale between different window sizes, screen resolutions (and in mobile devices, adjust to screen rotations).

Hum… you could draw your widgets *over* the linear layout and check for resize events of the main widget *while* correctly positioning your set of widgets in the scene. But that sounds a bit too much hack-ish.

I asked 2 friends about this very same issue and one suggested me to create a layout with this behavior. Initially, I was not sure about it, after all, I have never worked before with QGraphicsLayouts and I got almost no time to have something working.

Well, the good news are that it only took me a couple of hours to get this:

Explanation: it is a layout were you can add several widgets and move from one to another by calling next()/previous(). And since it is just a layout, can be inserted in another layouts (in this case, inside of QGraphicsLinearLayout).

Maybe a bit of code would help to explain… say that you have 2 widgets and you want to move next when the current one is clicked:

Item obj1, obj2;

SliderLayout *slider = new SliderLayout;

slider->addWidget(&obj1);

slider->addWidget(&obj2);

connect(&obj1, SIGNAL(clicked()), slider, SLOT(next()));

slider->setCurrentWidgetIndex(0);

and you are done.

The secret here is to keep hidden all the widgets (except by the current one) and in the slider event, animate the position of both widgets (the current and soon-to-be-current widget) while correctly repositioning the widgets in the scene (and setting to show state both widgets of course).

Since I have the movement methods on this layout as slots, I have to derive from both QObject and QGraphicsLayout (and that I’m not completely happy, anyone has suggestions to workaround that?).

I have tested this layout (integrated with *far* more complex widgets) in varied devices (from ARM@430Mhz up to Intel Atom@1.6Ghz))and it behaved pretty well, basically because I’m only animating the position of 2 widgets. It might happen that if you have an overly complex widget, that your hardware is not able to do the animation with good frame rate (but here you can workaround by hiding some of the content of this overly complex widget, and that will be probably the subject of my next post).

There are 2 other remarks about the code:

• I used Plasma SliderAnimation just because it was easier, but it could be replaced by a QPropertyAnimation
• Since Plasma Animations expect to receive a QGraphicsWidget, I assumed that you are going to supply a QGraphicsWidget to the SliderLayout. But the real requirement could be a QGraphicsItem, since it is the position that is being animated.

You can get the code here, my personal sandbox for experimenting with plasma animations and other stuff (please, please, we *do* need to migrate away from svn and start using git) and look for src/lib/sliderlayout.cpp and src/example/slidertest.cpp. I wonder when the feature freeze of KDE is over, if this could be part of libplasma.

Maybe this concept could be expanded so there would be a layout class and the animation behavior (fade, rotate, slide, etc) be defined by a delegate. Anyone is tempted to help me to develop this further?

libgcal 0.9.5 plus a video

It is being a quite busy week and it shows since it is being just a few days since previous release of libgcal.

This is a highly recommended upgrade, and also I point every pacman (Package Manager/Maintainer) to use version 0.9.5 of libgcal to create packages for your distribution. As Fathi Boudra (the debian packager of libgcal) pointed to me, release 0.9.4 was missing 3 public user functions featured in previous releases.

Now ABI has being restored, plus some extras:

• Support for IM field. This is not exported to akonadi resource yet, since it seems that in KAddressBook there is not an easy way to specify the IM type (i.e. skype, AIM, etc)
• As said previously, restored ABI (gcal_contact_get_phone, _set_phone, _set_mail will map to the prefered field)
• some memory leaks are fixed
• improved unit test coverage

The akonadi resource has not changed, so you can continue using akonadi-googledata-1.1.0 *with* libgcal 0.9.5.

And last, but not least, special thanks to Holger Kral who is helping me to make KDE support for google contacts near to perfection.

To close this post, a nice video showing kaddressbook updating a google contact with basically all possible fields.

libgcal 0.9.4 released

Sweet! But what the heck is this ‘libgcal’ thingie? For starts, the name can and is misleading, since it should read as ‘library for google calendar’ but in reality, it implements both Contacts and Calendar google data protocol.

When I got it started, back in February of 2008, it was supposed to implement just calendar, but later on I realized that adding contact support only required +25% of code on it (thanks for well modular software design). Back then,  there was no other good alternative for any C/C++ programmer that would fit the following requirements:

• easy to use;
• well documented;
• few dependencies;

So, I got my library started! After studying the google data protocol 1.0 (at the time) for while, I realized that using XPath would make my life way easier than say, browsing through the DOM tree searching for the attributes and tags that I wanted.

At that time, Qt didn’t have support for XPath (it only started with 4.5), so I went with libxml. For networking I used libcurl, which is fast/reliable and has great documentation (and a very welcoming community, from time to time I asked for help and always got answers for my questions).

From the very early beginning, I set a high quality standard in the development (after all, parsing XML in C is already prone to errors by itself) and followed a TDD (Test Driven Development) approach where *first* I write the test and *later* write the implementation of functions. Having an average of test coverage of 80% helped a lot when google released version 2.0 of the protocol (back in december 2008) and now more recently, version 3.0 of Contact’s protocol. I did the porting from version 1.0 to version 2.0 of the protocol in few hours, mostly because I could detect any regression by simply running the test suites.

IIRC in about 4 months I got the basic (authenticate, retrieve, add/edit/delete, query for updates) done and the library even got featured in the google official blog (that was surprising to say the least)!

So, the library was ‘done’, let’s put it to good use. I decided to integrate it with Opensync (it was rather cool, I got google contacts and calendar sync for my Nokia N95 over bluetooth working 6 months before google decided to release a syncml server for S60 devices). You can see a pre-jurassic video of this here. I think up until now libsyncml is a pretty good syncml implementation, it is just a shame that there is not a good UI bounded to it.

But I needed a good UI and the alternative seemed to write an akonadi resource. In just 3 weeks I got contacts working, while also implementing missing features in libgcal to make possible to do fast-sync (i.e. when you download only what has changed in server side). Contacts resource was done in just 3 days (I think this is clearly a good signal that akonadi API is well designed).

Developing the akonadi resources gave the opportunity to better understand how KDE community works and also to start running KDE trunk as my default desktop (after all, pre-packaged software are for sissies and developers should eat their own dog food).

So, why I wrote all this story? Well, to help to understand some numbers:

• 10 months ……. since last release (0.9.3)
• 6 distros ………. pre-packages libgcal (Debian, Ubuntu, OpenSuse, Gentoo, Mandriva, FreeBSD) and counting
• 2326 downloads .. directly from libgcal project website (hey, this is a source code tarball of a library and not some porn!)
• 20681 views …… reported by google analytics in a 1 year period
• 3000 ms……… the lag to ping google servers in a bad day in Manaus/Amazonas (yeah, truly it is unbeliavable how I managed to write a *networking* library in this enviroment but what doesn’t kill you makes you stronger)
• 6762 LOC ……. lines of C code (34% are unit tests)
• 76.5 % ……… current *real* code coverage (here I slipped a bit, it used to be 80%)
• 10th ……….. of most wanted KDE features

So, what this new release brings? For start, support for multiple email addresses, patch by Stefano Avallone (Andre Loureiro helped to fix the unit test) and migration to Google Contacts API 3.0. Next, support for structured names and several other fields (nickname, blog, etc) by Holger Kral. I think currently only IM field is missing from the library (but is quite easy to implement that).

You can have access to both the library and the akonadi resource in libgcal website. The only issue is that is required to purge your akonadi resource and do a slow-sync again because the ETags and urls of contacts have changed thanks to migration to version 3.0 of protocol.

So, what is missing in the library for a 1.0 release? The following features:

• support multiple calendars (easy to do, is a matter of using another URL as base to do the network operations)
• support recurrent events in calendar (thanks to the fact that google uses an invalid iCal to represent it, it gets tricky to implement it since a iCal parser would fail to read this data). An idea to implement this would be to ‘convert’ the invalid iCal from google to a valid one and do the opposite when sending data back to the google server.
• batch commit (nice to have, but not a hard requirement)
• port/rewrite it all to Qt (seriously, this was actually started already: http://code.google.com/p/libgdata-cpp/). Here I’m somewhat unsure, if Qt has support for the XPath/XQuery in Symbian (it seems that RTTI is not supported in this OS).

Oh well… so, why not give it a try? If you got the skills, go on and download the sources (please check the README and INSTALL files) and feel free to report to me how things worked (or not…).

If you are a normal user, I think in a couple of weeks it should get packaged for your loved distro.

6 months of plasma in 10 minutes

Not really… It is actually 7 months of “kdelibs/plasma” (or libplasma) repository activity in 15 minutes (but that would not sound really as attractive as a post title).

Today a fellow co-worker showed to me a really nice application: gource (like ‘source’ but with ‘g’ letter, maybe for ‘graphics’) written by Andrew Caudwell. This application offers some really nifty source code control visualization and supports git/mercurial and other source code control systems using some hacks.

Since internet speed (not even talking about latency…) in Manaus/Amazonas is lacking to say the least, I decided to use git-svn to checkout a specific revision of kdelibs/plasma directory and later I did a rebase to update the code with the trunk.

So, for your amusement, enjoy.

I have some hints about this visualization:

• in the first seconds there is an explosion of files (because I didn’t checkout the code from the very first commit in svn, is like the touched files warped inside of logs)
• the code seems to be rather modular (there are a well defined set of clusters on it)
• development speed is affected by some special dates (feature freeze, Christmas, Tokamak, etc)
• there are a quite varied number of contributors working in libplasma (which is good! KDE is a pretty open community)
• the overall champions in commits are (unsurprisingly!) Aaron and Marco