Category Archives: Projects

Talking about Poky and Yocto

I just returned from an excellent week in the Pacific North West of America where I attended Intel’s Open Source Technology Summit (OSTS), our internal open source conference.

The view over the laptop was amazing

Whilst there I presented a talk on Building Using Poky; the Yocto Project Build System the slides for which I’ve just uploaded to my Talks page. This talk was a high level overview of Poky – with the aim of presenting the system to the audience in such a way that they could begin to understand how it works and how to start getting things done with it. That and to introduce the GUI I’ve been working on.

I also uploaded the slides from last years OSTS talk, Using Poky to Develop for Embedded Systems, the information there is a little out of date in places but could still be useful to folks.

Cross-platform conundrum

A conundrum I’m having at the moment is that I have a vaporware home-time project which I’ve done a fair bit of design and research for. It’s really getting to the time that I should be writing some code, but I have a conundrum.

You see, this app has a very niche target user base of my (non-techy) friends. That means I need to write something which can be used on Windows, Mac OS X and Linux, whilst writing close to zero platform code (particularly for Windows, done that – not going back), and with minimal effort wasted (remember, home-time project).

First obvious choice is a web app, however after writing Blunderground I have some experience using JavaScript to develop an application and it’s not for meĀ (give me a compiled language any day of the week). Plus, I’d need some server-side pieces and then a server to host them on. I don’t have, nor do I want, a server to administrate.

Next we have Mono. While I like C# I’m put off by the ugliness of Gtk# on Mac OS X (and to a lesser extent, Windows). Of course, I can write a Mono core with native UI wrappers, but I don’t really want to maintain 3 separate UI code bases (or write host-specific code).

Third there’s that old faithful Java. The reason I won’t use it is simple, this is a GUI app and I hate Swing.

In four, there’s Clutter (and Mx) – brilliant. Only the non-Linux back-ends for Clutter will no doubt need some love, and for Mx are non-existent. Still… we could have a winner? I’m not very familiar with Clutter and I’m nervous how it would work out for what will basically be an IM client with a non-standard UI.

Finally, and by no means least, there’s Qt. The disadvantages to Qt are that I’d have to learn it’s intricacies (signals, slots, moc, etc) and obviously (as for Clutter) I’d need a host for each target OS to build the project on. That and using Qt would probably get me a flogging in the office.

Lots of choices, no simple answer. Bonus points if the platform has a decent XMPP library.

I guess that means fix and use Clutter/Mx, or write Qt and get flogged?


Recently I wrote about doing some hacking for the Palm WebOS to create a tube app for K. It’s now in a reasonably usable form so I’ve put up a noddy website and a clone of my repository is available on GitHub.

As it’s at a stage where it works for the person I wrote it for (and a bonus user) it’s unlikely to be developed with any sort of pace, too many other fun things to hack on!

I’ve decided against trying to get it in to Palms app store as I’m fairly certain TFL won’t be too happy with me redistributing their map. There are ways around this but I don’t feel it’s worth it at this time, at the very least I’d need to support rotation and likely a couple of other features before submitting it to the app store otherwise Blunderground will just be a target for flames.

Writing apps for the Web OS is really easy, it’s just HTML and Javascript. I kept falling over the lack of static typing and my ability to create a large typo to LOC ratio but not everyone uses the compiler as a crutch like I do.

The develop/deploy/test cycle, even with the emulator, is a touch clunky. Seems to me a lot of the testing could have been done in a browser with a suitable harness but I didn’t have the inclination to develop that, I shall check out Ares if I write another WebOS application.

Finally interacting with web services wasn’t as rosy as the cloud pushers would have me believe, a significant bulk of the development time so far was spent on trying to figure out how to parse the JSON data TubeUpdates was returning. In the end I gave up and switched to using XML which I manipulated with JavaScript DOM methods and had the functionality running in minutes.