UMPC, MickeySoft has just no taste

I'm exposed to an UMPC for two days and I really hate it. I wonder how companies can sell such things. Not even a freshly liberated, booted from haret, PDA running feels that crappy.

The list of annoying things is so long and it is getting longer by second. You can not use most of the installed applications as they failed to make keyboard input working, the hardware cursors keys are not rotated when you rotate the display, dual display and touchscreen input is ridicioulously broken. If your UMPC screen is monitor 2 and you use the touchscreen you can only control the first screen. The touchscreen is not working if you switch the rotation, you end up with an offset of 10 cm from you wanted to click and where MS thinks you clicked.... It is so broken, it is so Windows.

So I have to congratulate Microsoft for bringing the windows feeling to a portable device, well done! Oh yes, I'm really annoyed.

Findings of a night

This week I was introduced to the mini bar and enjoyed talking.

PyPy vs. smalltalk. Okay in contrast to my prior believe something PyPy is not that new. smalltalk to slang looks conceptually similiar to python and RPython. And smalltalk is implemented in smalltalk just like PyPy in python and there is a tool to create C code from the smalltalk image effectively creating the SmallTalk VM.

I should look more often into design patterns. With the new BitBake parser we build an AbstractSyntaxTree and want to evaluate it. Possible evaluations are a DOT directed graph (tree/forest), a classical bb.data dictionary or something I do not forsee, or another operation on the AST. What I created was a mixing class ASTAssigment(ASTNode,eval_factory(type.Assignment)) and this factory made sure to define an eval method. But this is completely wrong. First of all one would like to have a trait because the eval method should not modify the Tree but just evaluate. And second there is a nice pattern already it is called Visitor Pattern and basicly this is what I want. I want to visit each Node of my tree and evaluate in some way. I really should look into design patterns more often.

On a personal note I found out to have had jingoistic behaviour in the past. Note to self, do not call your future girlfriend anti-social because she uses hotmail, msn and windows and doesn't recognize she gives up her freedom this way don't talk with her or cope with it but don't be jingoistic in forcing her to look into Free Software.

Emily-Style: "Get Lost, I won't fix your computer"

DVB-H, TS2UDP

DVB-H is still IP based, but the lower levels of DVB-T and DVB-H are pretty similiar. I felt bored and wrote a simple mpeg soft demuxer that can extract PES and PSI. But now when DVB-T and DVB-H are mostly compatible where is the IP? Well it is inside the DSM-CC private section inside the Multi Protocol Encapsulation (MPE). So I felt bored and wrote this multiplexer, I analyse the DSM-CC private tables and inject the payload of the MPE into the IP stack.
So besides finding a wife, having children, planting a tree I only have to write my own IP Encapsulator, and copy Fabrice and abuse video cards as DVB modulators.
Besides the ever growing KDE developer community in Berlin, the DVB group is steadily growing as well. I'm glad to announce the sith lords doku and schmid are joining our conspiracy in Berlin. All your DVB-H belongs to us *har har*. Come on you knew I'm evil.

I have finally started on the BitBake parser again, oh what a day off from everything can do, and this is completely different to the python implementation and the planned C equivalent. It is still heavily based on Marc's Singers excellent work on Lex and Lemon (Thank you for showing me this wonderful tool) but this time everything is parsed into an AbstractSyntaxTree (AST) which we will evaluate later. Wow welcome to the wonderful world of parsing. The two constraints of this approach are. With the current parser we spend most of the time parsing the same .bbclasses over and over again. So by keeping these things as AST will help us to avoid parsing the same files over and over again. And the next constraint is to avoid expanding the bitbake data too often. At least this approach looks promising. I can parse almost all bb, inc, conf, bbclass files in about two seconds and consume only 50 megabyte of ram. So as numbers must go down we will separate parsing speed and evaluation speed. So parsing will always be fast and we will continue optimisation the evaluation. So no one can ever again complain parsing is slow. If it is slow then lex and lemon must suck, but they don't suck.

Usable Browser Engines

For another A-Team like fair project we built a mosaic of Images, live h264 videos and html sites on a huge 42" LCD panel. You have three rows with four columns and place an image, video or webbrowser widget at any position. Displaying the video and the image is quite easy. But the browser was a bit tricky.

So my first choiche was Python and KHTML. Well KHTML is attached to KIO and other services. So I found this python KDE example and changed it to display a specified url and changed KCmdLineArgs. Managing KCmdLineArgs in python was a bit tricks and documentation could have been a bit better. But we have dropped this approach because

• We had a dcopserver, kdeinint, KLauncher starting race. Sometimes instead of the site a "could not initiliaze KLauncher" error was displayed.


• It insisted on opening the Save As dialog for flash...

Okay my next try was gpe-mini-browser which uses gtk-webcore. The most amount of work was needed to make the old gtk-webcore snapshot compile on edgy. Then I had to hide the toolbar controls. Besides crashing when specifying http:// in parse_url gpe-mini-browser worked really well for the purpose and it had a good performance across the network. It displayed the binary content of the flash which was acceptable. We didn't use this application because I did not feel like creating packages for it. gpe-mini-browser uses libcurl to do HTTP transfer the benefit is the browser does not require any other daemons running. If you want to kill it, just kill the gpe-mini-browser. In contrast to KHTMLPart and KIO this was a big win for our purpose.

Now the monster enters the game. I know that the OLPC sugar project embeds Mozilla using python. So I looked for GtkMozEmbed bindings but there weren't any. I considered using the bindings from the SUGAR project but as I was behind a stupid firewall I was not able to git clone the laptop.org repository. So I googled for MozEmbed bindings and found the ruby bindings with an example which showed everything I needed. A bit more documentation wouldn't hurt but the example did the stuff I needed to do so the documentation was enough. This was the first time I coded in ruby, I'm not impressed though but it got the job done. After installing ruby, irb, gtkmozembed for ruby and recognising that it misses a dep on the gtk+ bindings I was able to copy and paste the example to the ruby shell and I saw the mozilla screen.

There were some pitfalls. Specially in getting the same code running on Dapper. A magic Gtk.init was missing to make the ruby script run on dapper but now our mosaic is powered by ruby and mozilla.


I would have preferred to use KHTML/WebKit but the time might not be ready. With WebKit and Qt4 and Curl we might get there. But sadly the cmake System of WebKit heavily depends on KDE trunk being installed. This needs some more fixing.

Hello Moko, The Future is Open

Wow, what a day. Today was the "Conference on open-source mobile phones mobilizes". And OpenMoko here and here was announced. Also the OpenMoko.orgwebsite lacks the glamour of the usual announcements it has something true geeks will love. It has Web SVN, and yes it contains the source for all these things they announced and even datasheets. To use a sentence the Qt Community Manager uses a lot. FIC and OpenMoko.org just get it. They know what geeks like and need. It is a Open Platform, build by people that care about Free Software. I think both Harald Welte and Mickey have a track record in understanding Free Software. Hey guys this is so great and it really helps Free Software, Linux and Gtk+ to move forward. This device and software is built with Free Software in mind this means they are GPL conform from day one, no hassle to wait weeks or month for the sourcecode of your toolchain, kernel just to fix a bug. This really makes a huge difference. Keep on rocking and I owe you Club Mate, alcoholic beverage!

I think OpenMoko is unmatched among all Linux Mobile platforms movements because it is build from community members and Free Software enthusiasts. And they focus on the important bits creating a platform and providing the basic set of applications and hopefully they will follow the release early and release often scheme! Let us make Free Software go forward!

Happy Birthday Qtopia, the status of Mobile Linux

Happy Birthday lovely Qtopia. It is another year you are truely proprietary. The last GPL release, patch release rsync version of Qtopia was one year ago. One year without a patch, update and only five to six releases of the commercial edition. Anyway Qtopia is still my all time favorite of proprietary software and I still believe there will be a GPL release of Qtopia in the future and I hope soon really means soon.
But for now happy birthday lovely proprietary piece of software and for the future I hope your bytes will be Free.