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?
🙂

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.

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.

Lies, big fat lies and benchmarks

There is the old saying, ‘there are lies, big fat lies and there are benchmarks’, but after my previous post about the jsanim, it was time to try to measure how good or bad the javascript based animations are when comparing it against Plasma::Animations (written in C++).

== what to measure? ==

The first task was to have a meaningful number and frames per second (FPS) sounds like a good idea. The only issue is that QGraphicsView will only update parts in the scene that need redrawing (besides it seems that there is not an easy way to access the draw events without subclassing). My solution was to set a counter for the Animation::updateCurrentTime() method that is called while the animation is running, given that the documentation says that “… neither the interval between calls nor the number of calls to this function are defined; though, it will normally be 60 updates per second.”. Maybe I should call it Function calls Per Second (FCPS). 🙂

Another important factor that can impact hugely is this kind of benchmark is both the hardware as also the graphics system used by Qt (and finally if the window manager has composite effect turned on). My test computer is a macbook (version 4.1), Intel Core 2 Duo (T8300@2.4Ghz), video Intel Mobile GM965/GL960), Qt 4.7 from master repository and I run the tests with composite disabled and got this results.

As the test application, I used the code available in playground/plasma/libs/jsanim, where a set of QGraphicsWidgets (each one drawing a pixmap) will run an animation group where 2 animations (zoom and fade) run in parallel followed next by a rotation.

== equal or not? ==

Next task is to extract any meaning from the results and I remembered what an old statistician professor that I had used to joke “Torture the data enough and it will confess”. I used to be good on this subject (back in the day I wrote some Bootstrap simulations and model fitting for biological data as also geostatistics  studies using R), but it is being 5 years since I last have done any statistical analysis, I was worried about making some mistakes while using more advanced methods.

So I went with the lazier approach and decided to use a boxplot, following bellow:

The js based animations seems to have a somewhat bigger variance (see second boxplot) but overall you can’t really tell if there is a difference between them (just in case, the p-values for t-student means tests was for each animation respectively: 0.54, 0.43, 0.86).

So… what about mobile? I did the same tests in a Nokia N900 (using the opengl and raster engines) and got this data, which yielded the following boxplot:

this time without the js variance and again without any sensible difference between js and C++ animations (p-values: 0.42, 0.16, 1).

== wrapping up ==

From the data (and after asking 4 different people to inspect visually how the animations were running in js X C++ apps), I can say that following the path of using javascript to code the logic of animations in Qt seems to be a valid approach with no sensible difference in performance. Kudos to QScriptEngine (and Qt development frameworks) for making it perform really fast.

There are indeed some issues in this study, following:

• CPU and memory usage: I measure it informally using ‘top’ and they seems to be on the same level, but a more formal benchmarking ideally should measure this variables;
• samples: I was a bit in a hurry and run each animation only 3 times (ideally a bigger sample like 20 should be used).

jsanim: current status

From my previous post about jsanim (javascript animations) where I explained the motivations about the idea, I’m writing to report the current status.

I got stuck while trying to create an instance of a javascript class from C++ side in QScriptEngine, but I was helped by khansen (you rock man!).

Being able to create an instance got to address an important issue in the first PoC: run more than 1 animation. Now each animation type will have a javascript class, where its instance will point to the animation target widget and hold the animation parameters. This design has some advantages:

• uses a single QScriptEngine object (implemented as a singleton);
• can run multiple animations;
• multiple animations can access the same widget;
• is more OOP oriented (the animation loop will call a method on the javascript class);

How fast (or slow…) is it to use QScriptEngine to animate a widget’s properties? What about a video?

Notes: it has 8 QGraphicsWidgets, 24 animation objects (zoom, fade, rotate), running in the Nokia N5800.

What is next is profiling and comparing it against our Plasma::Animation classes doing preferably the same type of work. But since it is still in the very early beginning, it is already looking promising.

Nokia Booklet 3G: KDE and plasma

As in the previous post, I wrote that the Intel GMA 500 drivers for Linux are problematic. The result is that trying to enable composite effects using OpenGL will result in rendering artifacts and crashes in both KDE and Gnome (in a side note, qtdemo will fail with “Application calling GLX 1.3 function “glXCreatePixmap” when GLX 1.3 is not supported!” but at least works with -graphicssystem=raster).

Last Sunday, I compiled Qt 4.6 and KDE from trunk  in the booklet and started to play with it to make it run well. The only way that I found for composite was to use XRender  (yeah, it will run way slower, but it is a workaround while we don’t have good graphics drivers).

As the result, the KDE effects based on KWin were running slow (so the workaround was to change the animation speed to ‘Instant’). The result of this hacks can be seen in the following videos, which I recommend watching in fullscreen (sorry about my Portuguese accented English):

Concluding this 3 parts saga:
– The Nokia booklet is a great hardware and Ubuntu Karmic support most of it out of the box
– Intel GMA 500 is at very best, a problematic GPU in Linux
– KDE and the plasma-netbook both runs smoothly in the booklet (even with lacking drivers)

Nokia Booklet 3G: unboxing

Last week I got a Nokia Booklet 3G borrowed for testing purposes (one of the advantages of working for INdT is access to some really shine new toys!). There are already quite a considerable number of reviews on this computer/mobile device/netbook, but quite a few comparing its size with other well know objects.

Which is a shame, since this computer really is thin and lightweight! So, for my fellow hackers delight, below follows some photos of it.

Booklet box

The box is in the Nokia (TM) blue, relatively thin and feels solid.

Booklet box open

Opening the box will reveal the booklet (at the sides, it is possible to find the accessories).

box contents

The acessories (manual, AC adapter, cleaning cloth, earphones, cellphone charger).

Stack of computers (Dell mini 9, Nokia Booklet, macbook)

Stack of computers (Dell mini 9, Nokia booklet, Macbook 13′)

Stack, right side.

Again the stack (pay attention how slim the booklet is!). The booklet has a slot for a SD card and the telephony simcard.

Stack (left side)

The other view of the stack (yes, it has HDMI output).

Of course after booting it up and having a look in the win7 install, I felt the urge to try ubuntu on it (as also KDE from trunk!). But this is the subject of the following post (stay with me).