bookmark_borderTesting a little Haiku

For a while now, I have been following the progress of the open source Haiku project, which aims to re-create BeOS 5. BeOs, for those of you that might not know, was a rather cool operating system developed during the late 90’s.

BeOS R5 Personal Edition, screenshot courtesy of WikiPedia Haiku

What amazed me about BeOS is that unlike many operating systems around at the time (and arguably, those around today) it:

  • Booted up and shut down in mere seconds (no suspend or hibernate trickery needed)
  • Wasn’t bloated to hell (sadly a trend nowadays)
  • Did multi-tasking right (e.g. didn’t start choking when one little app decided to do something a bit intensive)
  • Supported live file searches (before the advent of spotlight & co)

Although of course, it wasn’t all perfect. It did lack a few things, like:

  • Multiple user support (nowadays the norm)
  • Good hardware support (e.g. for stuff like 3d cards and network adapters)
  • Great third party support (apart from what you can find on BeBits)

Regardless, in 2002 Be Inc ceased operations and thus BeOS was more or less dead. That was until the controversial Zeta developed by Magnussoft came along. Controversial as it was often claimed that Zeta was developed without the permission of whoever owned the rights to the source code of Be OS. Safe to say, they nail hit the coffin earlier this year.

Luckily, Haiku is actually coming along quite nicely nowadays. After trying out the latest test image in qemu, I found it to be almost usable, with the exception of:

  • The networking which I couldn’t seem to get working properly (although the DNS did work, so its probably a qemu issue)
  • The system started to hang a bit when running one of the demo apps (although on the plus side I could still move the windows around freely)
  • The sound, which I guess doesn’t work due to lack of appropriate drivers.

Still, considering it was running in qemu with no kernel acceleration module, I thought it was quite responsive. In the future, I hope that the Haiku team will improve stability and hardware support so that developers will seriously consider targeting the Haiku / BeOS platform. Hell, maybe even i’ll try using it more.

Ultimately, I hope that software developers in general stop following the trend of more bloat, slower functionality. Can’t we all just follow examples such as Haiku’s and make something that is simpler and faster without all of the bloat?

bookmark_borderSSH Tunnel Manager

After reading Gary Vaughan’s recent blog post on MacBook Installation Applications 101, I decided to check out one of the tools he mentioned called SSH Tunnel Manager.

SSH Tunnel Manager

SSH Tunnel manager is a rather nifty tool which allows you to manage a list of SSH tunnels, which basically securely forwards ports on your own machine to a remote one.

So for example, if I had an administration control panel running on my web server, I might want to make it so that I could only connect to it locally (so there would be practically no chance of anyone on the internet accessing it). But I would still want to access it remotely, and the only way for me to do that is make an SSH tunnel which acts as if I am connecting locally on the machine, when in reality I am not.

Any would-be hacker would need to figure out the login details on my SSH server in order to have a chance of accessing the control panel.

Now whilst this app was great, I noticed something a bit disturbing about it. It turns out that its been quite a while since it was last maintained, and thus it it still a PPC binary, meaning if I run it on my brand new shiny Intel mac, I have to let Rosetta run, which is memory hungry and gobbles up precious CPU time!

Luckily, the developer also provided the source code to the application. So the solution was obvious: I needed to recompile this application as a Universal Binary, which means it will run natively on both PPC and Intel mac’s.

This didn’t end up being very hard, i.e.:

  • Download and unpack the source code
  • Open the project file in XCode (converting it to the new format)
  • Replace the ssh executable in the resources with the version from /usr/bin
  • Set the configuration to “Deployment” and build
  • Run it and hope it works

Thankfully for me, it built properly (with the exception of a few warnings, though they didn’t look too serious). So now I have a nice and shiny native version of the SSH Tunnel Manager on my mac.

In case anyone doesn’t want to go through the 5 step solution, or perhaps you don’t have XCode installed on your machine, here is a copy for you to download.

bookmark_borderExperiments with OpenLaszlo

Recently I decided to try out OpenLaszlo, the RIA platform from Laszlo Systems. Previously I have tried, but failed to get to grips with it. But the iPhone demonstration on the OpenLaszlo blog spurred my interest again.

OpenLaszlo Logo

OpenLaszlo is a bit like Adobe’s Flex, except that instead of just Flash you can output content for multiple runtimes, such as DHTML or J2ME. This is very interesting as it opens the doors for creating functional web-based applications which can be run on a multitude of devices.

LZPix, an example OpenLaszlo application

In a way, OpenLaszlo is the perfect solution for creating self-contained Flash or DHTML internet widgets, as a lot of the framework emphasizes the use of AJAX style requests to dynamically update information on the page rather than taking the aging “dumb terminal” approach where you reload the whole page.

Enough of the theory, I decided to try and make myself a little self-contained OpenLaszlo application. Its task was to get the latest updates off of Twitter, a popular web-based chat system.

Starting off

OpenLaszlo comes with a nicely designed presentation server which run’s off Tomcat. On this presentation server, you can develop and even deploy your applications. It is supposed to act as an intermediary between your application and any data it requests, which comes in handy in the case of Flash as it transcodes data such as images into a native format Flash can easily understand.

DataFlow for the example weather application

Thankfully, if you don’t fancy running a bloated Java application server just to deploy your OpenLaszlo application, you can choose to deploy it “SOLO” which means it run’s self-contained. Although of course you loose all the neat caching and transcoding that the presentation server can provide. But looking at the bigger picture, its not that much of a loss.

Being one who didn’t want to do things the easy way, I developed much of my Twitter application in the demonstration explorer (not the best environment it has to be said, although later on when I got to the deployment stage I moved the “lzx” code onto the actual presentation server).

Data binding & Replication

The first thing I did was to determine how I could get the recent updates feed from Twitter loaded into OpenLaszlo. Thankfully, OpenLaszlo provides a pretty powerful data binding system. You can take in XML from any source and create a rather feature full front end in minutes – provided of course you have read the documentation and know how to get from A to B.

Quite simply, in order to just view the data from Twitter, all I had to do was the following:

<dataset name="dset" request="true" 
type="http" src=""/>

<simplelayout axis="y"/>

<!-- Data replication -->
<view datapath="dset:/statuses/status">
<simplelayout axis="x"/>
<image datapath="user/profile_image_url/text()"/>
<text datapath="user/name/text()"/>
<text> - </text>
<text datapath="text/text()"/>


As you can see, I have a “dataset” which points to the xml feed for the recent activity on Twitter. This is referenced via the datapath in the view. There are also a few elements in the view which also reference XML elements in the dataset, relative to the datapath of the view.

Whenever the dataset is loaded, OpenLaszlo automatically replicates the view to show every “status” element in the dataset. It should also be noted that OpenLaszlo also has the common sense to delete the replicated view’s whenever you decide to reload the dataset (via calling “dset.doRequest();”).

You might also notice the “simplelayout” object which I have placed in both the root “canvas” and the replicated view. The purpose of this object is to automatically position elements in the element it is located – which is nice as it is one less thing for me to think about!

Polishing everything up

Now I could see the data from Twitter, I needed to polish everything up. Importantly, I needed a button to invoke the request on the dataset, and I needed a scrollbar to scroll the list of statuses which were replicated.

Twitter application header

The button was easy. I decided to add a header at the top which contains the button and also some text which tells the user if something is happening. As for the loading text, it uses OpenLaszlo’s useful constraints feature so it always appears in the right place relative to the width of the page (in this case, right aligned).

Twitter application scrollbar

The scrollbar was the hard part. I ended up having to nest the replicated views in another view in order to get the scrollbar to appear correctly (as otherwise the simplelayout would position the scrollbar below the list of statuses). I also had to play about with the width’s of the views and turn on the clipping so that when everything scrolled, the text didn’t draw over everything else.

The end result

After much frustration, here is the end result!

I also decided to add in a little fade-in animation when the images load, which makes everything look that bit cooler.

For reference, here is the code I ended up with. Feel free to copy and experiment with it!

<dataset name="dset" 
type="http" src="">

<simplelayout axis="y"/>

<!-- Header -->

<view name="header" width="${parent.width}" bgcolor="#CCCCCC">
<handler name="onclick">

<text name="throbber" x="${parent.width - this.width}">

<!-- Scrollbar container -->

<view width="${parent.width}" 
height="${parent.height-header.height}" clip="true">
<scrollbar name="scroller" axis="y"/>

<view width="${parent.width-parent.scroller.width}" clip="true">

<!-- Data replication -->

<simplelayout axis="y"/>

<view datapath="dset:/statuses/status" visible="false">
<simplelayout axis="x"/>
<image datapath="user/profile_image_url/text()">
<method event="onload">
parent.animate("opacity", 1, 1000, false);
<text datapath="user/name/text()" fontstyle="bold"/>
<text> - </text>
<text datapath="text/text()" fgcolor="#AAAAAA"/>



bookmark_borderThe Web on a PocketPC

Unless you have been hiding in the dark these past few weeks, you’ll have heard about Apple’s new product, the iPhone. The which I think is most most striking about this new mobile phone is not the cool multi touch interface, or the springy interface, or even its minimalistic look. Rather, it has a web browser that actually works properly!

Apple's iPhone

Sadly, whilst Apple may have seen the light and put the time and effort into making a good web browsing experience, the same cannot be said for a lot of other mobile device manufacturers.

Just to show you how bad things can get, I decided to try out a few web browsers on my PocketPC device, a Dell Axim X50V. For those of you who don’t know, it is one of Dell’s last PocketPC devices which uses Microsoft’s “Windows Mobile” (otherwise known as Windows CE). It has also got a nice VGA screen, giving 640×480 pixels of real screen estate.

Dell Axim X50v

The browsers I decided to try out are as follows:

In each instance, I tried 3 of my favorite websites, i.e.:

In addition, to make things a bit more interesting I only used the default portrait mode on my device, meaning the resolution was really 480×640 pixels.

Pocket Internet Explorer

For reference, I used the version bundled with Windows Mobile 5.

Youtube Desktop PIEYoutube Default PIEYoutube One column PIE

BBC News Desktop PIEBBC News Default PIEBBC News One column PIE

Techcrunch Desktop PIETechcrunch Default PIETechcrunch One column PIE

This browser comes bundled with Windows Mobile. Like its desktop counterpart, it struggles to correctly render a lot of the pages I visited. It also didn’t help when all the images and whatnot were drawn twice the size.

Although on the plus side, it felt much more responsive than the other browsers I tried!

There were a total of three display modes available, i.e.:

  • Desktop
  • Default
  • One column

Another interesting feature of Pocket Internet Explorer is that if you download a plugin from Adobe, you can enable support for Flash movies in the browser. Unfortunately it only supports up to version 7, and even then you will be lucky if you can get it to work properly on your typical run-of-the-mill Flash game.

One major show stopper issue I did find with Pocket Internet explorer is that the JavaScript support appeared to be substandard at best. For example when I tried YouTube, instead of the videos all I got was a JavaScript related error message.

Opera Mobile

For reference, I used the 8.65 beta.

Youtube Desktop OperaYoutube Fit to screen OperaYoutube Single Opera

BBC News Desktop OperaBBC News Fit to screen OperaBBC News Single Opera

Techcrunch Desktop OperaTechcrunch Fit to screen OperaTechcrunch Single Opera

I first tried Opera Mobile last year when they released a public beta. In all, I didn’t have any major issues with responsiveness. It also rendered a lot of the pages I visited correctly, and even had a “Fit to Screen” option where I could view the page scaled down width-wise so it fitted onto my screen – great!

Sadly this was the only browser that made a good attempt at displaying each web site correctly, although in Portrait mode everything tends to get a bit squished up.

With regard to display modes, there were three:

  • Desktop
  • Fit to screen
  • Single

Like Pocket Internet Explorer, it can utilize the Adobe Flash plugin for view Flash 7 content. Combined with the superior JavaScript support, you can actually use YouTube. However, the videos slow everything down a lot, for instance you can tell in the “fit to screen” desktop that it spent so much time playing the embedded flash videos that it didn’t want to load the images.

Unlike Pocket Internet Explorer, it supported tabbed browsing, which pretty much made sense on a PocketPC.


For reference, I used the 0.2 beta.

Youtube MinimoBBC News MinimoTechcrunch Minimo

Essentially, this is Firefox for your Pocket PC. Which considering the hardware constraints, does not bode well. To put a long story short, this seemed the least responsive of the browsers I tried. I also encountered a lot of bugs, such as when I tried typing into text fields using the on-screen keyboard, I sometimes could not get rid of it. There was also the occasional crash, right when I least expected it.

Oddly enough I could not find any way of explicitly changing the display mode, so I was stuck with the default.

Like Opera Mobile, Minimo supported tabbed browsing. Although I couldn’t help thinking that the size of the tabs was a bit on the small side (compared to Opera Mobile).

Unlike Pocket Internet Explorer and Opera Mobile, Minimo could not make use of the Adobe Flash plugin. Considering the relative disappointment with compatibility with Flash content though, its not much of a loss. Still, it would have been nice.

To conclude

In general, browsing the web on a PocketPC device is a major disappointment. The only browser which stood out was Opera Mobile, which is great if you are willing to shelve out the money to pay for it. Arguably though, a decent web browser should have already been included in Windows Mobile.

Perhaps in the future web browsers on your typical PDA’s and Mobile Smartphone’s will get better. Until then, one can only hope.