I'll change my habits a bit here, and write a personal note about what I've been working on recently. Some of you may know about it already, since I have begun to announce it, but probably to a smaller audience this far [1].

It's probably relevant to begin with some background information about all this, although even then it's difficult to know where to start.

Reinventing the wheel

For some reason I found the urge to start an Operating System project of my own, which began with a modified version of Debian GNU/Linux [2]. This goes as far back as 2001, which may seem like yesterday to many experienced UNIX users, but was just a year after my first installation of a distribution on my own computer. This turned into a LFS-based project [3], before becoming the DeforaOS project as it is today [4], with more or less the goal to re-implement a complete kernel and user environment.

That is to say, you may see a pattern here, and remind me that such time may be better spent improving the existing projects. While I would definitely agree that many Open Source projects need help (quite logically, otherwise I wouldn't have started my own), I will briefly summarize the reasons behind my choices:

• I am having fun, and learning in the process;
• back then, I did not have the technical means (eg cheap Internet access), let alone political power to influence much of the things I really wanted;
• with my projects evolving, I stuck with this work and choices rather than give it all up;
• frankly I still do not see myself having any political power now in the community, to do what I really want anyway;
• last but not least, I am essentially trying to implement a different design, which I believe is worth a try.

Of course this doesn't mean that I always make the same choices as a professional [5]. This experience has always been useful, even though a compromise in design I made to implement a working solution unfortunately hasn't succeeded to date [6]. But I have then been focusing a full year on the hackable:1 project instead [7], with a few releases along the way.

The Openmoko Freerunner

This is clearly another illustration of the "reinventing the wheel" approach. Why go all the way and create an Open Source smartphone from scratch [8]? It sure must be tedious, and from my experience and the information I have obtained in the process, I can say it sure was. And I can't say it was a clear, undisputed success either.

I'll be honest: I never liked the device itself. I found it ugly and bulky at best. I encountered the most annoying hardware bugs and subsequent frustration rushes. No need to mention the community fragmentation, which didn't help either. But today still, it sure has its uses, and is actually useful in plenty of ways.

Coding again

Burning out, having new opportunities, I parted ways and resumed work as a security consultant instead [9]. I could afford to take a first break in far-away land (thanks a.) and have fun creating software again, rather than feel like a packaging robot for what seemed to me as being broken code anyway.

I could manage to get a few bugs fixed in my current Operating System of choice (NetBSD [10]), and then turn a few more sub-projects of DeforaOS to be good enough that I began to (finally) use many of them on a daily basis.

The motive(s)

Owning a Sharp Zaurus [11] for a few years, I had already been thinking about an embedded version of the desktop environment while writing it. But I could do better; I could take my revenge on the Openmoko Freerunner instead. Still bitter from the outcome of my efforts while working with the device, I was convinced that I could do better. Be it true or not, as always there is only one way to know: trying it hard, whatever the reason.

After a quick glance at the Openmoko community, to no surprise I found its activity to be declining. Maybe this is not true and I was simply expecting it, but I think it's fair to say that the hardware is aging. Nonetheless, combined with hackable:1 it has the advantage to easily letting me run my own native environment. This is certainly not true of the more popular mobile platforms.

Trying a different way

As mentioned, I thought I could turn this phone into something more useful than it already was. This was based on the following assumptions, based on my personal appreciation:

• the existing projects are over-engineered;
• they have no global coherence concerning usability;
• they are often developed as regular applications, regardless of the hardware constraints.

Better then, some interesting and unusual features of the hardware are available and documented [12], some of which could turn into interesting security developments. I cannot pretend to have actually been able to do better, or implement all these fancy features, especially within this other month break; but here is where I am now.

The DeforaOS embedded desktop environment

First, I have spent some time improving and adapting my existing desktop applications to fit the Freerunner. I won't copy and paste what I have already written about it [13]. Instead, here is a summary of its current status:

• neither hardware buttons are required (nor currently used) for regular operation, as everything can be done on-screen;
• both panels are fully functional, with an integrated application launcher, and displaying the clock, hardware status (including registration, signal level and operator) and of course an application switcher;
• the on-screen keyboard is fast, although definitely not finger-friendly at the moment (xkbd embedded in the panel), and will be re-implemented from scratch;
• the contextual menus (as offered through a Gtk+ extension) could be more intuitively found;
• the file manager is functional, but could be better integrated with the freedesktop.org standards;
• the clipboard and drag&drop features from the same project could be improved as well;
• the homescreen functionality cannot be enabled at the moment due to how matchbox-window-manager handles it;
• DeforaOS' own window manager is not mature enough to be used instead at this point;
• the latest versions of the web browser cannot be packaged on hackable:1 at the moment, as it depends on a more recent version of WebKit.

I think this reflects quite well what is to be expected there.

The DeforaOS smartphone environment

Meanwhile, I have implemented a complete telephony application from scratch [14]. The design goals were:

• use Gtk+ and the glib libraries in C, and only relying on them and DeforaOS' libDesktop;
• embed the GSM daemon directly inside it;
• implement the core application with all the required functionality built-in (eg contacts, messages, phone calls, preferences...)
• let this application be as reactive as possible (eg single process)
• extend it through optional plug-ins;
• support hardware modems as broken as on the Openmoko Freerunner.

It's still far from being eligible as a regular mobile phone sold with a contract, but as of today this first set of goals was mostly met. Some essential features are still missing:

• adding, editing and deleting contacts;
• maintaining a phone log;
• sending DTMF codes during calls;
• storing the messages sent;
• support for delivery reports;
• preferences dialogs;
• entering the PUK/PIN2/PUK2 codes;
• switching to data mode;
• call forwarding...

Most of them are not challenging anymore, and are just a matter of taking a few hours this and there to get them done.

Where is gets interesting

One of the first parts I believe I should emphasize in this post is the plug-in support. First, it allows full integration with the actual, underlying hardware platform with all the code clearly separated. This is the case on the Openmoko, where:

• a first plug-in takes care of supporting profiles, by requesting a ring tone, triggering the vibrator and so on;
• the hardware plug-in catches these events and turns the relevant components on and off.

Secondly, it allows extending the functionality in lots of different ways, from PulseAudio support to DBUS and potentially FSO integration [15], without mentioning webcams, GPS positioning [16] and then more.

And there's more.

SMS encryption

One of the first additional security features I have been thinking about is SMS encryption [17]. While not being specific to the Freerunner, it is certainly an interesting platform for such a feature. My current implementation, while not being cryptographically strong at the moment, can already be demonstrated as a working Proof-of-Concept [18].

More than that, it is maybe time to think about a common, interoperable way to implement this feature. It looks like things could be moving towards this direction, with new projects emerging like TextSecure [19].

Cell tracking and geotagging

Not unlike some other phones, but probably in a more accessible way, the Freerunner supports an "engineering mode". It is basically a monitoring mode [20][21], much like the one on your regular 802.11abgn wireless card (except you can't sniff traffic, yet [22][23][24]).

While not being as featureful and polished as kismet [25], my current implementation (couple of days old) can already illustrate this concept.

The future

With a project as promising as Osmocombb [26] able to run on the Freerunner, I can only let you guess where all of this can be going. There are still many things to be done with this hardware, and of course I am also hoping to run my software on other devices as well, like the ones from ROAD [27], GizmoForYou [28], Nokia [29], Glofiish [30], HTC [31] and Palm [32] among others.

If you would feel interested in any of this, do not hesitate to let me know [33]. Better, you can use the development infrastructure directly [34]. I will welcome your feedback and ideas, free patches and hardware, consider contracted projects.

Thank yous

To conclude, I have omitted one of the reasons behind all of this in this post. I had the pleasure to be invited to the Nokia Hackfest in Berlin mid-March this year [35], and then be honoured with a free N97 and N900 device. They have both proven very helpful while developing this software already.

Of course there's a number of people and projects who are also a great help to me every day. I can only hope to be helpful to you, too. Cheers!

[1] http://www.defora.org/os/news/3363/Introducing-the-DeforaOS-smartphone
[2] http://www.debian.org/
[3] http://www.linuxfromscratch.org/
[4] http://www.defora.org/
[5] http://people.defora.org/~khorben/cv.en.html
[6] http://runningbear.org/
[7] http://trac.hackable1.org/
[8] http://www.openmoko.org/
[9] http://www.duekin.com/
[10] http://www.netbsd.org/
[11] http://www.trisoft.de/slc3200.htm
[12] http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem
[13] http://www.defora.org/os/news/3362/DeforaOS-as-an-embedded-desktop-environment
[14] http://www.defora.org/os/project/3343/Phone
[15] http://www.freesmartphone.org/
[16] http://realtimeblog.free.fr/
[17] http://www.cryptosms.org/
[18] http://www.passageenseine.org/hackevents/confidences-par-sms
[19] http://www.whispersys.com/
[20] http://nobbi.com/monitor/index.html
[21] http://www.gnokii.org/screenshots.shtml
[22] http://www.gnuradio.org/
[23] http://cryptome.org/jya/crack-a5.htm
[24] http://reflextor.com/trac/a51
[25] http://www.kismetwireless.net/
[26] http://bb.osmocom.org/
[27] http://www.road.de/
[28] http://www.gizmoforyou.net/
[29] http://www.nokia.com/
[30] http://www.glofiish.com/
[31] http://www.htc.com/
[32] http://www.palm.com/
[33] http://people.defora.org/~khorben/place/wiki/13/Contact
[34] http://www.defora.org/os/project/bug_list/3343/Phone
[35] http://www.youtube.com/watch?v=5jW3VDqvzLs

Hello hackable:1 users !

Serdar Dere, from #openmoko-cdevel managed to get a devroom at this year's fosdem for the openmoko community !
First things first, huge thanks to him.

Second, we get the room on Sunday morning and the schedule is here. As you can see, it is full of talks and hackable:1 has a slot.

Meet you there ! Who's coming ?

EDIT: The slides

In this article I'm going to describe a new feature which will be available in rev5: h1settings.

h1settings is a library which handles the global settings of the phone. It is a basic wrapper upon some gconf keys and has functions to :

• read and update key values
  
• listen to gconf key changes
  

Currently, only a few keys are available :

Device states :

• gprs on/off : /desktop/h1/phone/enable_gprs
  
• gsm on/off : /desktop/h1/phone/enable_gsm
  
• gps on/off : /desktop/h1/gps/enable_gps
  
• wifi on/off : /desktop/h1/phone/enable_wifi
  
• bluetooth on/off : /desktop/h1/phone/enable_bluetooth
  

Power management :

• power management enabled / disabled

The idea behind this library is to add loose coupling between components. For example the power management key is used by the gsm applet when a call is in progress (to fix this silly bug: http://trac.hackable1.org/trac/ticket/42 ) in order to disable power management (i.e. suspend). The gsm applet does not know how to disable PM but neod knows.

Currently, all the actions related to key states except gsm are handled by neod, the central daemon. It registers itself for these keys changes and sets the state of the devices. For the gsm part, it is handled by the gsm applet because it has already everything needed to switch on/off the antenna.
 
Another advantage is that an independant settings app can be built very easily without any dependencies with the underlying system, and this app already exists : h1settings.
See some screenshots below :

Within my position for the promotion of free, open-source hardware solutions in general (and currently, telephony in particular), I am of course trying to keep in touch with the latest developments in this field. Eventually, I have met the fine people at ROAD, a small company in Berlin developing a phone: the Officer S101.

If you don't know about it already, its form-factor will remind you of the Nokia Communicator: from the outside, it looks like a regular candy-bar phone, but it also reveals a full keyboard and wide-screen display when opened. What interests us here is that its inside is open, too :)

The device is not in production yet, but they have been so kind as to let me borrow a sample for a while, which I demonstrated during my hackable:Device workshops at HAR2009 by the way. This is where I managed to install hackable:1 on the phone.

On the hardware side, it was difficult to let it be easier to test. Let me stress first that this was a pre-production device, and all of this may be subject to changes! So here we are:

• the phone has an internal flash memory but can also boot on an SD card, which is conveniently replaceable without opening the phone or even removing the battery,
• the first partition of the SD card must be formatted as a FAT filesystem,
• I was provided with two second-stage bootloaders: one that boots the phone from flash, and the other which updates it.

Therefore, it was just a matter of copying the correct bootloader on the SD card, along with the root filesystem to flash if desired.

About the software now, this device happens to use the same architecture as the Openmoko Freerunner within Debian, "armel". One only has then to choose the right packages, configure them accordingly and generate a filesystem archive.

First, I have added a generic device definition file in trunk/build/profiles/ROAD-Officer.include:

DEBIAN_ARCH="armel"
STRIP="arm-linux-gnueabi-strip"

The "STRIP" line is necessary because of the way we are currently cross-compiling Debian packages: the native tools are unable to strip the binaries cross-compiled. Therefore, strap:1 is currently doing it instead, while generating the images.

#this device is a phone
. "profiles/generic-phone.include"
#add bluetooth support
. "profiles/generic-bluetooth.include"
#add GPS support
. "profiles/generic-gps.include"
#add touchscreen support
. "profiles/generic-touchscreen.include"
#add wifi support
. "profiles/generic-wifi.include"

This should be self-explanatory :)

#packages
#Debian
PACKAGES="$PACKAGES
[...]
xserver-xorg-core
xserver-xorg-input-kbd
xserver-xorg-input-tslib
xserver-xorg-video-fbdev
zlib1g"

Unlike the Openmoko Freerunner, which has its own dedicated X server, we are using the generic framebuffer-based X server. It just works :)

#specific kernel
#FIXME still needs to be packaged
PACKAGES_BLACKLIST="xserver-xorg-video-all"

In order to gain space, we are blacklisting this meta-package: xserver-xorg-core dependencies are actually satisfied with at least one video driver installed, which is the case here.

Next comes the actual profile definition, in trunk/build/profiles/ROAD-Officer-user.profile:

. "profiles/ROAD-Officer.include"
#blacklist packages to gain space
PACKAGES_BLACKLIST="bash
debconf-i18n"
#additional dependencies adjustments
PACKAGES="$PACKAGES
debconf-english"
CLEAN_DOC=yes
CLEAN_LOCALES=yes

This was directly taken from the Openmoko Neo1973 profile, which has tough space constraints on the flash. Here we do not have such limitations, however it made the testing process slightly faster.

Anyway, after some more tuning in trunk/build/packages, it was time to generate the filesystem archive:

$ ./build.sh VENDOR=ROAD MODEL=Officer PURPOSE=user archive

At this stage, the only missing bit was the kernel. I simply used the one already flashed onto the device, but I still needed some modules. They were of course provided to me in source and binary forms, but I don't think this kernel tree is available publicly at the moment. I am sure it will be as soon as the ROAD developers can manage.

Unfortunately, I could only get this far yet. It boots all the way to the graphical user interface, where the Om2007.2 design does not really fit the rather wide screen. We are currently working hard on the next release, rev5, and focusing on the Openmoko Freerunner first, but I will be resuming this work soon enough!

When cross-compiling hackable:1 packages, we are relying on the stable emdebian toolchain to compile our programs. Apparently, there has been a problem last week, where the toolchain was erroneously recompiled and from then on depending on packages not available on Debian Lenny.

We have coordinated this issue with emdebian's team, and are glad to announce that everything seems to be back in order.

If you have been upgrading your hackable:1 cross-compilation environment during this window, there is a simple way to get it to work again:

# apt-get remove --purge libgcc1-armel-cross
# apt-get install gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

Then you should be able to cross-compile again!

One thing I'll certainly work on in the upcoming weeks is boot time improvement.
So far, booting takes quite a long time. But instead of looking at my clock when powering up my FreeRunner, I installed a tool to go deeper in the boot process and analyse its (non-)performance.

This tool is called Bootchart-lite, a clone of the well known Bootchart on desktop systems.
That's a basic rewrite from embedded systems that create similar logs as its big brother bootchart, meaning bootchart can compute them.

If you are interested in working on boot time improvement, you should install it !

Uboot configuration

The bootloader must be configured to add a kernel parameter. Here is the way for Uboot. Adapt it for Qi if you use it.

    # apt-get install fso-utils # from FSO
    # mkdir /tmp/uboot && cd /tmp/uboot
    # dfu-util -a u-boot_env -U env.u-boot
    # uboot-envedit -i env.u-boot -p > env_modified.u-boot.tx

Edit env_modified.u-boot.txt to tell the kernel to use bootchart-lite instead of init as first process.

    boot_menu_timeout=300
    bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6 quiet bootlevel=8 init=/usr/bin/bootchart-lite console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot
    ...

    # uboot-envedit -i env.u-boot -f env_modified.u-boot.txt -o env_modified.u-boot
    # dfu-util -a u-boot_env -D env_modified.u-boot

* Install the packages *

On your FreeRunner running Hackable:1, install bootchart-lite: (As of september, 18, it is packaged for daily builds, and will be packaged for rev5)

    hackable1# apt-get install bootchart-lite
    hackable1# reboot

Get data and render the image

On your computer, install bootchart-view (from the big brother bootchart project), and get the logs.
Then, render the PNG (or SVG) image.

    # apt-get install bootchart-view 
    $ scp -r root@hackable1:/etc/bootchart-lite .
    $ cd bootchart-lite
    $ tar czf bootchart.tgz *.log
    $ bootchart -f png bootchart.tgz

Analysis

That's the most difficult step :) !

I'll have a look on that later, I'm focusing on rev5 for now.

Eh ! There are "beta2" images available on http://build.hackable1.org. Would you give it a try ?

Please let us know how you like it and if bugs remain !

Dear Hackable:1 users,

After rev5rc1, we spent hours and hours debugging this or improving that to finally get the rev5 out today. Yep, that's right: hackable:1 rev5 (Codename: Chuck) is there!

First of all, you can grab the different flavours (user for the flash and developer for the SD) here: http://download.hackable1.org/rev5

Changelog
Here are the changes since rev4:

+ End users matters

• Most of the software stack now runs under the 'hackable1' user, for security purposes.
• SMS proper implementation
• The contact list bug has been found and fixed!
• Power management improvements, suspend works, bluetooth and wifi are no longer turned on by default.
  
• An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...) as well as time and date.
  
• We created a new theme to celebrate this new release!
  
• We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
• For those who used to love the games on OM2007.2, we put them back !
  
• Boot time seems to have been improved a bit

+ Power users / developers matters

• This rev5 release has entirely been built from the automatic build system.
• A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.
• Debugging has been disabled (boot time improvement)
• Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
• Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
• You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html

• CDBS is now used for some packages.
• the package h1packtools contains a CDBS rule that may suffice for simple programs with the autotools
• this rule also enables cross-compilation ; it is based on previous works on this subject
• Git repositories can now be used as sources for remote projects.
  

Where can I find it? Where can I get it? I didn't understand last time, so I ask again : what is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5.

All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.

It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

• Marcus Bauer (mbauer)
• Jérome Blondon (jbl2024)
• Sébastien Bocahu (zecrazytux)
• Pierre Pronchery (khorben)
• David Wagner (Deubeuliou)
  

We'd also like to thank all the testers, among them most notably Bearstech employees, and regular contributors/users of hackable:1, who kept us going forward.

What should I expect next?
Due to a very good number of good reasons, which could all of them be summed up by a minute of one of khorben's rants against libgsmd, we'll switch to Freesmartphone.Org for rev6.
We will also switch from xserver-xglamo to xserver-xorg for the sake of more responsive graphics.
On the developer side, we will of course continue to improve the packaging system and lower the entry barrier.

All in all, more reliable GSM & suspend, and almost all the features one may need. Stay tuned!



The hackable:1 team

Dear Hackable:1 users,

We are glad to announce that, after long & thorough efforts from the development team, after a bunch of testing hours, after a long time spent on arguing whether we should include this or that feature, we made it: hackable:1 rev5rc1 (Codename: Chuck) is there!


Here is a changelog of corrected bugs and added features from rev4.

Changelog

+ End users matters

• Most of the software stack now runs under the 'hackable1' user, for security purposes.
• SMS proper implementation
• The contact list bug has been found and fixed!
• Power management improvements, suspend works (well almost each & every time, sadly we're still hunting GSM issues for that matter)!
• An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...)
• We created a new theme to celebrate this new release!
• We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
• Boot time seems to have been improved a bit

+ Power users / developers matters

• This RC1 and the upcoming final rev5 release are now built from the automatic build system.
• A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.
• Debugging has been disabled (boot time improvement)
• Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
• Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
• You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html

Where can I find it? Where can I get it? What is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5rc1.
All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.
It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

• Marcus Bauer (mbauer)
• Jérome Blondon (jbl2024)
• Sébastien Bocahu (zecrazytux)
• Pierre Pronchery (khorben)
• David Wagner (Deubeuliou)

We'd also like to thank all the testers, among them most notably Bearstech employees, and regular contributors/users of hackable:1, who kept us going forward.

What should I expect next?

Due to a very good number of good reasons, which could all of them be summed up by a minute of one of khorben's rants against libgsmd, we'll switch to Freesmartphone.Org for rev6.
All in all, more reliable GSM & suspend, and almost all the features one may need. Stay tuned!

Last week, I have spent some time figuring out how to improve the status of the phone stack for the hopefully-soon-to-be-released development version of hackable:1 [1]. There are unfortunately a few major problems:

• asking the PIN code multiple times [2]
• network registration rarely effective
• SIM contacts and messages not always fetched [3]
• sending messages not always working
• no GPRS support at all (from a GUI like [4])

It sounds like a lot, but I'm pretty sure the cause is the same for all: interaction with the gsmd. It's somewhat strange, since the development sources were synchronized with rev4...

Therefore, I've been using libgsmd-tool extensively for a while. First, I realized that the code for its "shell" mode (-m shell) is somewhat fragile. Unfortunately, the design of this part doesn't make it trivial to fix.

Anyway, then, I've been using the "atcmd" mode as well (-m atcmd), while working on the GPRS interaction in particular. Here comes the funny part: since this command then basically works like a serial console, why not tell pppd to use it instead of the actual serial device?

gsm-tool - (C) 2006-2007 by Harald Welte and OpenMoko, Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

ATZ
STR=`ATZ'
RSTR=`OK'

It makes even more sense in this context, since the phone stack no longer runs as root, and therefore shouldn't be allowed to tinker with the gsmd daemon at all anymore (eg "/etc/init.d/gsmd start/stop").

The first part was easy; patching libgsmd-tool to:

• output errors to stderr,
• remove the local echo (eg "STR=...")
• write the response without escaping (eg "RSTR=...")

The second part took me a bit more time, but is actually trivial when you know it: using the "pty" directive of pppd instead of "/dev/ttySAC0". The change goes in /etc/ppp/peers/gprs:

##
## pppd options
##
#/dev/ttySAC0
pty "/usr/bin/libgsmd-tool -m atcmd"

It actually works up to a certain point:

• I doubt that connectivity reports still work while the connection is up (eg signal quality, etc)
• gsmd probably currently doesn't expect this to happen,
• there should be some kind of pass-through mode, where libgsmd-tool would pipe the data in and out of stdin to and from the gsm daemon.

With this solved, this could be a rather elegant solution to be able to use GPRS without interrupting gsmd. I guess it would also allow the other applications sharing access to the daemon to keep the communication socket open during that time.

For the record:

Sep 16 15:47:34 syn pppd[321]: pppd 2.4.4 started by khorben, uid 1000
Sep 16 15:47:34 syn chat[518]: send (ATZ^M)
Sep 16 15:47:34 syn chat[518]: expect (OK)
Sep 16 15:47:34 syn chat[518]: OK
Sep 16 15:47:34 syn chat[518]:  -- got it
Sep 16 15:47:34 syn chat[518]: send (AT+CGDCONT=1,"IP","internet.eplus.de"^M)
Sep 16 15:47:35 syn chat[518]: expect (OK)
Sep 16 15:47:35 syn chat[518]:
Sep 16 15:47:35 syn chat[518]: OK
Sep 16 15:47:35 syn chat[518]:  -- got it
Sep 16 15:47:35 syn chat[518]: send (ATD*99***1#^M)
Sep 16 15:47:35 syn chat[518]: expect (CONNECT)

[1] http://www.hackable1.org/
[2] http://trac.hackable1.org/trac/ticket/254
[3] http://trac.hackable1.org/trac/ticket/264
[4] http://people.defora.org/~khorben/place/blog/60/New-project--gprs-for-hackable-1-on-the-Openmoko-Freerunner

Custom Linux kernel for the Openmoko Freerunner on Hackable:1

We've been using FSO/debian’s kernel package in Hackable:1 till now (mid-september).

I decided to package a custom one for Hackable:1. Why ?

• to disable debugging that I suspect being a cause of a slow boot (debug + screen output, wich is slow on the Freerunner)
  
• we may need it for other projects in anear future
  
• for hackability: easy to patch, modify the configuration… while still being integrated in hackable:1 thanks to its packaging
  
• because I can :)
  

developper information

You should already know our build system, if not, take a look at :) – http://trac.hackable1.org/

As of september, 13, 09:

• Kernel sources come from git://git.openmoko.org/git/kernel.git
  

  although GTA02 is now supported in the mainstream kernel 2.6.31, the support of gta02 hardware is uncomplete.
  

• The kernel config can be found in the debian/ directory after patching with packages/linux-image-gta02/linux-image-gta02.diff.
  It was copied from pkg-fso and modified a bit, mostly in order to disable debugging features.

• As it uses git, you cane asily build your patched kernel, using another git repository and another commit tag. (you only have to modify debian/changelog a bit, or use bump.sh)
  

general informations

Three packages are created:

• linux-image-gta02: Linux kernel plus the basic kernel modules that are necessary for the Openmoko Freerunner to run correctly
  
• linux-modules-gta02: common kernel modules you may need, when pluging a peripheral for example
  
• linux-moremodules-gta02: other modules, that are built for a few people who may need them (not for everybody end-user)
  

[temporary] call for module sorting

Please let me know in which package should modules go… :)

All modules that are compiled go to linux-moremodules-gta02 first, then, some are moved to linux-image-gta02 and linux-modules-gta02 according to the module lists : debian/linux-(image|modules).modlist

This is an ugly script to get the correct path of modules to add in the .modlist files

As you may know, we are willing to migrate to FSO. As part of it, we made ogsmd running on H:1 and we will rewrite phone-kit to use libfso-glib instead of libgsmd.

Until we get all the stuff packaged, here are the step to make ogsmd running on a Hackable:1 rev4 installation.

Install the framework

We will use a git version that I know working. On your computer:

git clone git://git.freesmartphone.org/framework.git
cd framework
git checkout 17898fc0f73453c11d1b1e8db57f8e8a0cfbc943 .
cd ..
scp -r framework root@192.168.0.202: # I assume that it is you FR's IP

SSH into your freerunner and:

cd framework
python setup.py install
cd ..

Install the muxer

We will use SHR packages which a copy of them is on our trac.

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk"
ar -x fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk"
ar -x libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk"
ar -x libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

We will use SHR frameworkd.conf:

wget "http://git.shr-project.org/git/?p=shr-themes.git;a=blob_plain;f=frameworkd/frameworkd-config-shr/om-gta02/frameworkd.conf;hb=HEAD" -O /etc/frameworkd.conf

If the following file doesn't exists, libgsm0710mux segfaults (see http://trac.freesmartphone.org/ticket/467)

cat << __EOF > /etc/abyss.conf
[omuxerd]
autoopen = 1
autoclose = 1
autoexit = 1
[session]
mode = 1
framesize = 98
port = /dev/ttySAC0
speed = 115200

[device]
wakeup_threshold = 6
wakeup_waitms = 200

__EOF

And if this one doesn't exists, fso-abyss claims it doesn't provide any channel

touch /etc/cornucopia.conf

A file may have permissions problem, first check it:

ls -l /usr/lib/dbus-1.0/dbus-daemon-launch-helper

If the group isn't messagebus:

chgrp messagebus /usr/lib/dbus-1.0/dbus-daemon-launch-helper
chmod u+s /usr/lib/dbus-1.0/dbus-daemon-launch-helper # because chgrp removes the SUID

Launch Ogsmd

Let's kill the old stuff...

killall -9 ogsmd

...and launch te framework:

frameworkd -s ogsmd

If no error (Python Traceback) occurs, we can move on:

libfso-glib sample
Install libfso-glib

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk"
ar -x libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

Install the sample (See the sources)

wget http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/sample-libfso-glib_0.1-1_armel.deb
dpkg -i sample-libfso-glib_0.1-1_armel.deb
sample-w

You will be asked for your PIN (unless you are already authentified) and you will be registered.

Then, it will catch several signals. after that, you can call yourself and see the signals "CallStatus" be matched. These signals are sent whenever the status of a call (which ID is specified, i.e. "1") change. (ie "incoming" or "release"). See FSO doc for further information.

And now what ? You can already, by reading freesmartphone.h, find any interesting function you need and write nice applications.

Any question ?
If you have any question about this manipulation or about Hackable:1, feel free to ask in the comments.

You can fin updates of this tutorial on our trac

I wrote a while ago about how to cross-compile Debian packages, and within the
hackable:1 Linux distribution in particular. I'm glad to say that I managed to
find a decent work-around for a problem I mentioned last time: dh_shlibdeps
couldn't work.

dh_shlibdeps is in fact a wrapper around the dpkg-shlibdeps command. This
command analyzes every binary and library shipped in a package being generated,
in order to automatically list their dependencies. This can be problematic when
cross-compiling, since the binaries don't match the current architecture, and
may not even match the database of installed packages.

The trick here is to force dh_shlibdeps to:

• look into the cross-compilation root folder,
• read the dependency tracking information specially written for the occasion.

This is now done using this syntax in hackable:1:

$ dh_shlibdeps -l/usr/$(DEB_HOST_GNU_TYPE)/lib:/usr/$(DEB_HOST_GNU_TYPE)/usr/lib \
-- -Ldebian/shlibs.cross

where:

• -l does the former directly,
• and -L does the latter through dpkg-shlibdeps (escaped with --).

With this fix, the packages cross-compiled are almost as good as native ones,
stripping being the last culprit (only eating space). This will require a
modification to all the packages, but it will then help a lot with automated
images generation.

As a lot of you know, at Bearstech, we're very serious with hackable:1 and what we intend to do with it.

If you were to ask to a typical hackable:1 developer, he'd probably say he crafts his code as he would paint an art piece or carve a nice wooden table. All the development is done for your GTA02 pleasure.

As can prove the following pictures, left alone, our GTA02s are not that happy. See how they seem to whine or just how they seem alone, oblivious to the fact that they're with their peers:



But then, a little bit of H:1 magic, and look at how they seem to shine in happiness, all directed towards the same common objective, united to fight for their common goal:

As part of our research & development on mobile devices we are currently participating on a project from ANR, the Agence Nationale de la Recherche - the french national agency for research. This project is about mobility and multihoming and we do the Linux terminal part.

Currently we are investigating the transport layer and here specifically SCTP. SCTP is on the same layer as TCP or UDP but combines advantages of both protocols and adds multihoming capability.

SCTP opens independent so called streams on one connection. In order to distinguish it from TCP a connection is therefore called an association.

Another difference with TCP is that SCTP is a message oriented protocol and not a stream oriented protocol. This is very handy for the application developer as one does not have to collect and reassemble the data packagewise but gets it delivered in a whole.

Other nifty features include automatic network interface detection together with a heartbeat and automatic failover to any other known working network interface.

Last not least the streams are indepent. This can be used for reliable delivery on networks with package loss by sending a message over every stream. If one sends a message with TCP ten times and one gets lost then the subsequent messages get stuck until the lost package has arrived. This is known as head-of-line problem. With SCTP streams are independent and thus delivery on other streams continues even when a package on one stream was lost and therefore is blocked for retransmission.

That's it for today for the Bearstech Labs, stay tuned!

Hey everyone,

Long time no see. At last, we decided to setup a blog in order to keep you all in touch with what you need to know about hackable:1, and about the new things we do.

Stay tuned, as we're bounded to put a lot of things here sooner than later!

I have just released the first version of gprs, a tool to ease connections to the GPRS network on hackable:1, for the Openmoko Freerunner in particular. The project's homepage is here:
http://people.defora.org/~khorben/projects/gprs/

It's still alpha quality but already works in some conditions. I have uploaded a couple screenshots as well. I hope to package it soon, it will then be instantly available via the daily builds.

mkdebpackaging.sh: a minimalistic, crosscompilation-aware replacement for dh_make

the first step to create a debian package is usually using `dh_make', that creates a few important files that are used to describe the package(s):

• debian/control: which packages are generated, what is necessary to build, install…
  
• debian/changelog: gives the version number of the package and keeps traces of everything that happened to that package.
• debian/rules: a Makefile describinghow the software should be built
  

why did I wrote a replacement for dh_make ?

• dh_make does not support take care of crosscompilation-only CFLAGS or LDFLAGS so that we had to tweak every debian/rules templates each time. Copy & paste is boring and time-ineficient.
  
• dh_make creates a somewhat “too big” Makefile for our needs.

How to use it

• cd into a software source directory (remember that directories should be named something like softname-X.x (X.x being the version)).
  
• execute the script:
  $ /path/to/mkdebpackaging.sh -m “Sebastien BOCAHU” -e “sbocahu-AT-bearstech.com”
  
• edit debian packaging templates (files into debian/)
  
• build the package:
  $ dpkg-buildpackage -us -uc # for native compilation
  $ dpkg-buildpackage -us -uc -aarmel # for ARM crosscompilation
  

Review it and give your point of view !

I wrote it quite quickly and many things can certainly be improved, so please tell me :)
Patching ltmain.sh (libtool) can fail, so that you have to dig into it by your own.

This weekend, i played with nitrogen on my freerunner :

The funny thing is that it is a full web app with the webserver running on the freerunner. Thanks to the nitrogen framework, the code is not bloated as usual and is quite simple.

Example : the clock is refreshed by the server every minutes with these simple statements:

body() -> 
	Body = [	
    	#panel { class="h1-logo", body = [#image { image="/images/hackable1.gif"} ] },
	    #label { id=clock, text="10:14"},
    	#label { id=mylabel, text="" }
    ],
	wf:comet(fun() -> clock_update(clock) end),
	wf:render(Body).

clock_update(Clock)->
    {_Date, {Hour, Min, _Sec}} = erlang:localtime(),
    Value = io_lib:format("~2.10.0B:~2.10.0B", [Hour, Min]),
    wf:update(Clock, lists:flatten(Value)),
	wf:comet_flush(),
	timer:sleep(1000*60),
    clock_update(Clock).

Last but not least, the client runs well on my laptop too :

So we have the best of the both worlds (web & desktop) :

• access to native resources thanks to erlang
• event driven code with nitrogen (push with comet)
• customized ui (jQuery)
• distributed client (example : accessing the contact list without installing crappy software)

The main drawback is performance (for the ui part) and memory consumption (i need to make some tests to figure out exactly).

The source code for the nitrogen/erlang part is available here : http://blondon.fr/blog/public/web_s... I'll post the whole app (html, media and css) asap.

There is a very nice and fast alternative to using dfu-util to flash images on the Openmoko Freerunner phone:

• boot the developer version of hackable:1 on an SD card
• use dd like this:

# cat Hackable1-Openmoko-Freerunner-user-daily-rootfs.jffs2 /dev/zero | \
     		| dd of=/dev/mtdblock6

for the root filesystem, and:

# cat uImage.bin /dev/zero | dd of=/dev/mtdblock3

for the kernel.

Even better, if you don't want to create a temporary copy of the image to flash, transfer it on the fly via SSH:

# cat Hackable1-Openmoko-Freerunner-user-daily-rootfs.jffs2 /dev/zero | \
     		progress ssh root@192.168.0.202 dd of=/dev/mtdblock6
     [...]
139853824 bytes (140 MB) copied, 278.255 s, 503 kB/s

Just omit progress if you don't run NetBSD, or use either this port or this version.

I'm using the gprs almost every days during my train trips. It works like a charm although it does not use the muxer. Here are the detailed instructions to use the muxer :

• change MUX=no to MUX=yes in /usr/bin/p and /usr/bin/x
• change delay from 5 to 10 in /usr/bin/x (lines 65 & 69)
• in /etc/ppp/peers/gprs :
  • line 36 : comment the /dev/ttySAC0 option
  • line 42 : uncomment the updetach option
  • line 43 : comment the nodetach option

reload the gui stack (/etc/init.d/xserver-hackable1/restart), wait for registration and launch the p script.

Now you can use the gprs and use the phone as the same time (but the gprs connection will hang when calling)

By the way, in order to improve the phone experience, the latest svn version of the openmoko-gsm-applet now handle the gprs automatically :

• start when the registration is done
• stop when starting a call
• stop when receiving a call
• restart when call is finished

TODO :

• use some gconf keys to check if gprs is allowed to start (see http://trac.hackable1.org/trac/wiki/settings#Settingsspecificationpage )

Wifig available – documentation about packaging and crosscompilation for Hackable:1

Wifig

I've packaged jbl2024’s wifig, an application for easily configuring wireless access.

For now, packages aren’t available on the hackable:1 repository. You can find them on my website:

• libcommongui0
  
• wifig

Wifig requires (missing in the stock hackable:1 rev3 release):

• libcurl
  
• udhcpc
• wmiconfig
  

Please review it !
It needs to be polyshed (be added on the menu, for example)

Documentation about packaging and crosscompilation for Hackable:1

I've wrote a bit of documentation about packaging, crosscompilation and possible problems with the crosscompilation envrironnement:

• crosscompilation & packaging documentation
  
• crosscompilation environnement problems & fixes
  

I hope this kind of documentation would help people to contribute :) !

I was finally able to create my first cross-compiled Debian package this evening. This wasn't without a lot of pain, and some issues remain. Still, it's worth mentioning how to reproduce it, along with the problems that I have more or less solved along the way.

Requirements

It's somewhat easier to start from hackable:1's cross-compiling environment. In fact there are still a few glitches to get it truly working, as always just create tickets if you get stuck (or solve something yourself).

pkg-config 0.23

In contrast with the current autoconf/automake/libtool's nightmare, pkg-config has managed to make life easier. This is particularly true since its 0.23 release and fix for the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables. In our case, they are set as follows:

export PKG_CONFIG_LIBDIR="/usr/arm-linux-gnueabi/usr/lib/pkgconfig:/usr/arm-linux-gnueabi/usr/share/pkgconfig"
export PKG_CONFIG_SYSROOT_DIR="/usr/arm-linux-gnueabi"

This does two important things:

• prefix the relevant CFLAGS and LDFLAGS flags with the path to the cross-compiled include and library files;
• forces pkg-config to only look at the definition files for packages installed in the cross-compilation environment.

Unfortunately, Debian does not include pkg-config 0.23 yet. I have explained how to install it from source, but even better I have packaged the patched 0.23 release in hackable:1. It will appear from the upcoming build bot soon.

libmokoui2

Unlike jbl2024 with neod, I have settled on libmokoui2. Here's a summary of the issues I ran into.

$ dpkg-buildpackage -rfakeroot -us -uc -aarmel
[...]
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [config.status] Error 77
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

Here's what said in config.log:

configure:2950: arm-linux-gnueabi-gcc -g -O2  -Wl,-z,defs -lX11 conftest.c  >&5
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/arm-linux-gnueabi/bin/../../lib/libX11.so when searching for -lX11
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/arm-linux-gnueabi/bin/../../lib/libX11.a when searching for -lX11
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status

The solution here is to force the LDFLAGS, as follows:

ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
CROSS= --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
LDFLAGS=-L/usr/$(DEB_HOST_GNU_TYPE)/lib -L/usr/$(DEB_HOST_GNU_TYPE)/usr/lib
else
[...]
./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs $(LDFLAGS)"

This works much better. We even got rid of -lX11, which should not be necessary: it is already required by the other libraries which will be used.

libtool nightmare

This is what drove me nuts again. I am not the only one:

« You might play with compiler and linker flags, try to hack and understand the libtool shell script (best of luck if you can decipher it), and end up cursing the ancestors of those who ever came up with such a dumb system. »

...and so I read it, and cursed endlessly. Thousands of lines of shell stress-testing code. To put it shortly, libtool is re-generated everytime you run ./configure, which appends ltmain.sh to some configuration variables.

At this point, depending on which LDFLAGS you're using, libtool will have a life of its own, sometimes replacing -lname by /usr/lib/libname.so, sometimes not (and ignoring most other flags). This got wrong in our case; in fact, libtool was correct in picking up *.la files (libtool's own library description format) in /usr/arm-linux-gnueabi/usr/lib, but it was blindly trusting them as they mention the libraries are stored in /usr/lib instead.

The solution should have been as "simple" as using -inst-prefix-dir (which I did not know about, and found by reading the code). Unfortunately it wasn't and I had to patch ltmain.sh to obtain what I feel is the correct fix:

test -f "$inst_prefix_dir$add" && add="$inst_prefix_dir$add"

This checks if the library is in the staging directory, which takes then precedence over the normal path.

dh_strip and dh_shlibdeps

I was totally expecting them to break: dh_strip hardcodes strip as the executable to run (instead of $(DEB_HOST_GNU_TYPE)-strip). Likewise, dh_shlibdeps will have to be modified to support cross-compilation. So I temporarily disabled them both.

And the winner is...

It feels good when it works:

dpkg-deb: building package `libmokoui2-dev' in `../libmokoui2-dev_0.3+svn4878-1_armel.deb'.
dpkg-deb: building package `libmokoui2' in `../libmokoui2_0.3+svn4878-1_armel.deb'.
dpkg-genchanges  >../libmokoui2_0.3+svn4878-1_armel.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload (original source is included)

It's not so bad, I learned some :)

Hello Planet,

am just testing my blogging set up here, more posts with real content to follow soon.

Barcamp à SUPINFO Marseille le 17 avril

Un barcamp aura lieu le vendredi 17 avril à SUPNFO Marseille.

J'y présenterais l'OpenMoko, Hackable:1, et plus généralement le projet de Hackable Devices de Bearstech qui m'intéresse beaucoup.

N'hésitez pas à venir nous rejoindre, que vous ayez un OpenMoko où non !

Différents thêmes seront abordés, et je présenterais également NetBSD, pkgsrc et Xen sur NetBSD lors de ce Barcamp.

Plus d'informations ici :)

Venez nombreux !

The openmoko-today app actually implements a kind of finger scrolling, but i find it very weird. I launch applications instead of scrolling every time i try to scroll.
In order to achieve finger scrolling, i have created a scrolled window with an event box above. The scrollbars are hidden and i'm listening to the button-press, button-release and motion-event signals to handle everything.

How to scroll the window

1. The initial Y position is saved in the button-press callback.
2. In the motion-event callback, we have the current Y position. A delta is calculated between theses 2 values
3. This delta is applied to scroll the window (by changing the GtkAdjustment value).

How to detect a mouse click instead of a scrolling action

In order to detect mouse click instead of scrolling :

• i launch a short timer when the user click on a button.
• When the timer expires, the button is saved in a variable and is activated.
• The timer is canceled whenever the motion-event is fired (and the button variable is cleared).
• When the user raises his finger (button-release signal of the eventbox), if the button is still here, the clicked signal is fired.

Implementation

The source code for the finger scrolling system can be found in libcommongui .

For an example of usage, see wifig

Erlang works out of the box on hackable:1

Here are the steps to make a little gtk app :

• install erlang :

apt-get install erlang

Download gtknode at http://code.google.com/p/gtknode/ Then :

./configure --prefix=/usr
make
make install

• test and enjoy :

%%%-------------------------------------------------------------------
-module(testerl).

-export([start/0]).

-record(widget, {id, name}).

-define(G(C,A),gtknode:cmd(hello,C,A)).

create_button(Winstruct, Label)->
    Id = ?G('Gtk_button_new_with_label',[Label]),
    ?G('Gtk_box_pack_start', [get_vbox(Winstruct), Id, false, false, 5]),
    ?G('Gtk_widget_show',[Id]),
    Widget = #widget{name = "Name", id=Id},
    add_widget_to_struct(Widget, Winstruct).


get_vbox(Winstruct)->
    [Vbox] = dict:fetch(vbox, Winstruct),
    Vbox.
    
    
add_widget_to_struct(Widget, Winstruct) when is_record(Widget, widget)->
    Widgets = dict:fetch(widgets, Winstruct),
    dict:store(widgets, [Widget|Widgets], Winstruct). 

add_to_struct([], Dict)->
    Dict;
add_to_struct([{Key, Value}|Tail], Dict)->
    DictBis = dict:append(Key, Value, Dict),
    add_to_struct(Tail, DictBis).

start() ->
    gtknode:start(hello),
    Win = ?G('Gtk_window_new',['GTK_WINDOW_TOPLEVEL']),
    ScrolledWindow = ?G('Gtk_scrolled_window_new', [ 'NULL', 'NULL']),
    ?G('Gtk_container_add',[Win,ScrolledWindow]),
    ?G('Gtk_scrolled_window_set_policy', [ScrolledWindow, 'GTK_POLICY_NEVER', 'GTK_POLICY_ALWAYS']),

    Viewport = ?G('Gtk_viewport_new', ['NULL', 'NULL']),
    ?G('Gtk_container_add',[ScrolledWindow, Viewport]),
 
    Vbox = ?G('Gtk_vbox_new', [false, 0]),
    io:fwrite("Vbox = ~p~n", [Vbox]),
    ?G('Gtk_container_add',[Viewport,Vbox]),
 
    But = ?G('Gtk_button_new_with_label',["butté"]),
    
    ?G('Gtk_widget_set_name', [But, "button"]),
    ?G('Gtk_box_pack_start', [Vbox, But, false, false, 5]),
    
    ?G('Gtk_widget_show',[Win]),
    ?G('Gtk_widget_show',[ScrolledWindow]),    
    ?G('Gtk_widget_show',[Viewport]),
    ?G('Gtk_widget_show',[Vbox]),
    ?G('Gtk_widget_show',[But]),
    ?G('GN_signal_connect',[But,clicked]),
    ?G('GN_signal_connect',[Win,destroy]),
   
    Winstruct = add_to_struct([{window, Win}, {vbox, Vbox}, {widgets, []}], dict:new()),
    loop(Winstruct, But).


loop(Winstruct, But) ->
    receive
        {hello,{signal,{But,clicked}}} ->
            io:fwrite("widget : ~p  ~p~n",[But, clicked]),
            io:fwrite("winstruct = ~p~n", [Winstruct]),
            WinstructB = create_button(Winstruct, "toto va a la plage"),
            loop(WinstructB, But);
        {hello,{signal,{_,destroy}}}  ->
            gtknode:stop(hello)
    end.

erl -sname anode@localhost
(anode@localhost)1> c(testerl).
(anode@localhost)2> testerl:start().

I just had the other day the opportunity to see my parents using a navigation system for their first time. Actually it was a "PNA", a PDA form factor system specifically designed for the task of navigation. I have to add that my Father is engineer and that my parents have a computer since 10 years. Nevertheless the user interface was all but intuitve to them. Without my help they would have never succeded to get the thing running.

Apples iPod was not the first mp3 player, yet its success is based on its superior usability.

To quote Antoine de Saint-Exupery:
"It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away."

My point is that lots of software is way to overengineered for the non-geek user. Too many features, too much technical stuff under the hood, while forgetting about the main purpose, whether this is playing mp3's or bringing you from A to B.

Apart from watching people using software I have learned a lot from Kathy Sierra's blog "Creating Passionate Users".

Actually I wonder if part of google's success is simply based on the fact that the front page www.google.com has never gotten cluttered with other stuff like yahoo or msn.

And a last note: I can't use my car radio without the manual - I'm not joking. In fact I simply refuse to read the manual for a radio. Long ago the days when there were just two turning knobs: on/off-volume and search a station.