Wednesday, February 25, 2009

Inkface+pygame v0.2.0

As per the plan for v0.2, I am ready with a working implementation of inkface. I also made few more design decisions after my last design post. Here are the highlights:

1. All code is in python
2. For X11 surfaces, pygame is used.

I found that pygame (python bindings for SDL) is a mature library for drawing on X11 surfaces. It also has some optimizations which help in 2D animations. There is also OpenGL support, but I do not plan to use it inside inkface library. It is also well supported on Maemo.

I have written my favorite twitter client app with the new inkface-pygame library. The following video demo shows, how I could quickly code 2D scrolling animation with the help of pygame.



The v0.2.0 is delivered as a tarball. I have also updated the inkface wiki with some getting-started tips.

Sunday, February 22, 2009

Smooth scrolling with Inkface+pygame

Preview of what's coming out later in the week. A v0.2 drop of inkface-pygame package for maemo and others should be ready in coming few days.

Saturday, February 14, 2009

Inkface v0.2 update and automated GUI testing

As I posted earlier, my work on v0.2 of Inkface is on track. It's implementation of an SVG library entirely in python, with the goal of dynamic rendering in mind.

This new implementation can now render some basic SVG shapes - rectangles, paths (except for arc), linear and radial gradients. Following video shows some of these shapes.



I spent most of today to write a regression test framework for this library.

Typically it's difficult to automate regression testing of a GUI library/app. But in this particular case, it is possible. The idea is to save SVG image's rasterized buffer into a PNG image, when we know it's correct by visual inspection. As new features are added to the library, the regression script rasterizes the same set of SVG images and compares their raster buffer with the that loaded from PNG files saved earlier. If new changes have modified the rendering, then the new rasterized buffer will be different from the loaded from PNG image.

You can find the regression script here. In fact, the above video is the same script run in visual inspection mode.

Friday, February 13, 2009

Testing Android (Koolu Beta 3) on Openmoko Freerunner

[My Openmoko Freerunner hadn't got much love in a long time. So its battery discharged to absolutely no charge. Then I realised that I have got a deadlock - FR cannot turn ON without battery and the battery won't charge unless FR is ON (because the firmware can't negotiate enough current from USB port to charge the battery, the running FR kernel can do that). Anyway, after coming to India I got a cheap instrument that tests and charges generic cell-phone batteries like FR's. The device's simplicity is amazing. It has two metal probes that can be adjusted to make contact with the battery terminals and with help of two buttons you can either test battery's charge or start charging it. Point is, the external charging worked.]

Now the more important topic...

As the Freerunner came back to life, I decided to test the latest Android images on it. Openmoko wiki has details of all (three so far) efforts trying to get Android running on FreeRunner. I decided to try Koolu's images. They are frequently releasing new images and their latest release is billed as Beta 3. Flashing the phone was straightforward - just followed the instructions.

Once the phone booted into Android (the first boot seemed very slow, but subsequent boots took 1 minute as I timed them), I could see what's all the Android noise about. This is my first experience with Android (saw it a bit in emulator, but not much). Android has rendered the best GUI on the screen of this phone so far. I was impressed with some animation effects (whatever happened to glamo's limited capabilities to do accelerated graphics - although I am not sure yet if these effects are done in h/w).

Most importantly, I got the wifi working on this phone first time. No other distro I had tried in the past has enabled wifi of this device. Android, easily scanned and detected my wireless network. A small problem came, when entering the WPA2 key. Note that the only official Android phone out there (HTC G1) has hardware keyboard, so Google has been slow in implementing a virtual keyboard. However I found a keyboard after some exploring (dunno if it's Google-added or some community effort). This keyboard is not perfect, but it works. The problem is, it is not accessible when WPA2 key entry dialog appears. So I can't tap in the password. After looking at Koolu's release notes, I figured one workaround is to type the password in Notepad app and then paste it in the password box. That worked.

After connecting to wifi, I tested the browser, visiting many sites (yeah mostly those tweets some of you read ;). Another impressive app is email. Configuring my gmail account with it was a 2-step cake walk and I was in my inbox in no time. I could also compose an email without much trouble.

Sadly however, the GSM is not working. I am using Tata Indicom's SIM card - which should be in GSM 1800 band (and my Openmoko is 850/1800/1900). But still it didn't detect any network (It didn't work even with the Qt image I had earlier - so I won't blame Android for it). I read that the GSM libraries in Android are not yet completely open, so there are some difficulties there. I need to learn the GSM Modem commands to debug this issue.

The accelerometer works. There is an app named Amazed that lets you navigate a ball using the accelerometers inside the FR. It's really cool.

I don't expect GPS to work, (although the antenna icon keeps radiating green waves) - because GPS satellites don't like me. :)

I tested an alarm app, which confirmed that the vibrator and sound also work great.

The 'Global Time' app has that 3D revolving earth that's depicted in some youtube videos. But its FPS is not so great, I believe there is no h/w acceleration there.

I also browsed through the software repository. Installed a game 'MiniSpaceWar'. It installed correctly, but I guess it was too heavy for FR, it took forever to load and then crashed Android, leading to a reboot.

Unfortunately, I couldn't get a screenshot tool for android. So can't post any of them now. But if I manage to get any, I will tweet them.

Saturday, February 07, 2009

Clutter animation paths with Inkscape+Inkface (v0.1.3)

While I am working on inkface v0.2, I will keep releasing dot versions for 0.1.x that will have some improvements that are independent of altsvg backend. So I have posted v0.1.3 source tarballs.

Only major improvement in v0.1.3 is the exporting of path data of SVG path elements. This path data can be used by clutter based applications to create "Knots" (animation paths along which objects can move). Check out the following video.



In this app, four paths were drawn in Inkscape. Then using inkface v0.1.3 library their path data was made available to clutter app. The clutter app created "BehaviourBspline" using this data and made the ball and star move along these splines.

As can be seen, any complicated paths can be created using this method. Without it, one will have to calculate coordinates of each point along which one wants to animate (very tedious to calculate control points for Bézier curves).

v0.1.3 source tarballs: libaltsvg, inkface

The clutter app is a single python script available here (also part of inkface tgz). You are looking for element_to_bspline