WimpWorks v2.39 released: compatible with RISC OS zero page protection

WimpWorks, our RISC OS integrated development environment for desktop app production, has been updated to version 2.39 to fix a couple of bugs that resulted in zero-page access.

The current development version of RISC OS, 5.23, is bringing in zero-page protection to increase the system's resilience to system crashes and causes errors in programs that attempt to access it. Although WimpWorks' access to zero-page wasn't the cause of any crashes as far as we were aware, we welcome the incrased strictness of the system.

Users who have WimpWorks v2.30 or above can upgrade online for free. Users of earlier versions can upgrade for a small fee.

A fully-featured demo version of WimpWorks is available for free and is compatible with all RISC OS 3 machines and above, the full version is only £39.99, and it is also part of the NutPi bundle from RISC OS Open Ltd. for the Raspberry Pi.

The perfect laptop backpack: Booq Cobra Squeeze vs. WaterField Designs Staad

I've been looking for a new, slim, stylish, minimalist, professional-looking laptop backpack that can store a bit more than the Solo Universal Slim - not least because a Dell XPS 13 is slightly longer than a Macbook Air 11" and won't fit.

After an exhaustive search (see the full list of all 33 bags), I narrowed it down to two:

1. Booq Cobra Squeeze ($195, but they often have 20% off codes around US holidays)
2. WaterField Designs' Staad ($319-$329)

Neither bag is cheap, and both are a bit heavier than I wanted. But both companies offer 30 day, full refund policies as long as the bags are unused; allowing you to see them in the flesh.

My standard test contents in the below consisted of:

• MacBook Air 11"
• iPad Mini
• MacBook charger (with US plug)
• Mini DisplayPort to HDMI adapter
• Mini DisplayPort to VGA adapter
• MicroUSB cable
• Small travel umbrella
• Small bottle
• Small lunchbox
• Snack

• 

  Booq Cobra Squeeze: front view

• 

  Booq Cobra Squeeze: side view

• 

  Booq Cobra Squeeze: side pocket with trendy Github water bottle from JavaOne 2015

• 

  Booq Cobra Squeeze: side pocket with umbrella

• 

  Booq Cobra Squeeze: everything from the contents list above inside

• 

  WaterField's Staad: Two models - Stout on the left, Slim on the right

• 

  WaterField's Staad: Two models - Stout on the left, Slim on the right

• 

  WaterField's Staad Slim: side view when full with the contents above

• 

  WaterField's Staad Slim: everything from the contents list above inside

• 

  WaterField's Staad Stout: side view when full with the contents above

• 

  WaterField's Staad Stout: everything from the contents list above inside

• 

  WaterField's Staad: the addition of some elastic to the straps makes it look even better

Booq Cobra Squeeze

My first impressions were that it's a nice bag, but it wasn't as slim as I was expecting. The curved style was good at providing structure, but also meant it was always the same thickness, regardless of what was in it. The laptop compartment was a little large for the svelte Macbook Air, but the addition of a small elastic corner strap and good padding meant it didn't seem to be a significant problem. The internal organisation was decent and, as you can see in the photos above, you could squeeze in a large water container in a side pocket, if you were happy to leave the flap open. Personally, I also found the grey a little light in colour: a darker grey would look more professional, while still providing a bit of variety over the standard black seen everywhere. YMMV.

Unfortunately, the combination of the depth, and the straps didn't quite lie properly at the top of my shoulders, meant it had to go back. Booq were brilliant about it: 2-day USPS shipping of the bag cost me another $8, but the money was refunded to my credit card straight away; with no hassles.

WaterField Designs' Staad

Everyone who's a customer of WaterField Designs sings their praises, and their Staad backpack seemed to fit the bill. It comes in two variants, Slim and Stout. Most reviews on the Internet are about the Stout, and they're mostly positive (with Carryology's Drive By an alternative take). ZDNet and Jim Kubicek provide useful hands ons with the Slim model.

I ordered the Slim and it did fit my test packing in that the Cobra Squeeze did. Just. So I ordered the Stout as well to see if that'd be a better fit.

After much consideration, I've decided to keep the Slim: it looks more professional, and holds what I need it to on a daily basis. It's also possible to squeeze in a bit more than you expect, but its slimness, and the lack of the extra width, make it the overall winner for me. As with Booq, there were no problems with returns: WaterField Designs refunded the money for the Stout immediately upon receipt (this time, 2-day USPS shipping cost $11.15).

We've also added some elastic around the straps to keep the spare, dangling, lengths tidy; this makes it look even smarter - and perhaps something WaterField could consider adding as standard in future.

Timbuk2 Classic Messenger: how much can it hold?

As with wallets, I'm always on the look out for a good, small, lightweight bag. Day-to-day, I use a Solo Universal Sling which perfectly fits a MacBook Air 11", iPad Mini, some business cards, pens and - when needed - the laptop charger:

The bag's definitely small (a few extra millimeters of length on the MacBook and it wouldn't fit) and weighs only 380g. No extraneous weight: very happy. It looks alright but isn't perhaps as professional as I'd like, and a sleak/small backback would look better and be better to carry for longer periods. But, as a commuting bag for day-to-day travel, it's fine.

However, sometimes I have to take overnight flights. Usually I try to travel with just a small carry on roller suitcase and my laptop bag, but when big suitcases are in the hold or I want to be able to quickly stash/access a hoody or sweater, a larger travel bag is useful. After some Googling, I decided on a Timbuk2 Classic Messenger Bag (medium). This isn't a full review, there are plenty of those on the Internet, but I had real difficulty trying to find out how much it could store. The answer is "plenty":

Certainly the medium size would be far too big for a day-to-day laptop bag for an 11" MacBook Air; but for convenience in having only a single bag on a plane (change of clothes, some toiletries, laptop etc.) whilst also having it be smart enough to use as a laptop bag on its own when I arrive, it seems to be just about spot on. It's also not too heavy at 880g.

MyFord Touch: LCARS wallpaper

I'm not (too) ashamed to admit to being a sci-fi geek and, in particular, Star Trek. On my current assignment, I've had a few rental cars with a Ford Fusion (a Mondeo in the UK) being the latest.

With a large touchscreen, running "SYNC by Microsoft", the MyFord Touch software is generally regarded as pretty poor with a litany of upgrades breaking or removing functionality, and long promised items - such as the "AppLink" available on the non-Touch system - being undelivered.

However, it does have one nice feature: you can provide your own 800x384 pixel wallpaper for the home screen. Googling turned up a few nice ones, but none provided the look I wanted. So, an evening spent with the GIMP produced:

Which, in place, looks really effective:

The phone is mounted using a Mountek nGroove Snap and Google Nexus charger, and is running 6 LCARS (available for both Android and iOS) in this screenshot, though it tends to be running Ulysses Speedometer and Google Maps when actually moving.

JavaOne 2013 - Starting the Future

JavaOne is a brand which is recognised by Java developers the world over. Held in San Francisco, it may have suffered slightly since Oracle bought Sun (and it got relegated to be the smaller, sibling, conference of Oracle OpenWorld), but it still has an excellent vibe, great sessions and fascinating exhibitors.

Sunday's technical keynote covered Java's prevalence and how Java - and Java developers - power the Internet of Things. This thread carried through the various speakers, with a chess-playing robot powered by a Raspberry Pi and, of course, Java.

Today, the sessions kicked off in earnest, with Gil Tene's 08:30 talk on How NOT to Measure Latency providing some interesting techniques for measuring and demonstrating performance throughput. The tools, hdrHistogram and jHiccup are definitely worth a look.

Real world estimation

Simple requirements rarely mean small estimates

There's been a lot of fuss on Twitter and the technology blogs about the news that "fixing" the clock on the BBC homepage would take "100 staffing days". Is it really that complex to show an accurate clock?

There had been a complaint that it wasn't necessarily accurate, as it was a simple JavaScript clock showing the local time on the user's computer. From the article in Ariel, the BBC's internal magazine:

The decision to remove the clock follows a complaint from a member of the public, who said it merely reproduces the time stored on a computer's internal system, whether this is accurate or not.

He added that there is no labelling which makes clear the clock isn't independently verified and, indeed, may not be 'factually accurate'.

Reaction

"In fact it should be possible with a single line of JavaScript and perhaps a single line of say PHP back on the server. The clock wouldn't be millisecond accurate but in most cases it would be correct to the second." -- IProgrammer

"I always assumed it showed the correct time. But what gets me is further on in the article it states that it would take around 100 staffing days to make the changes involved in switching to an independent clock. Whaaat?" -- 4Networking

"After being forced to remove its website clock BBC estimates it would take 100 days to build a proper one! Really?!" -- @JamesBarnesEsq

"The joys of working for a large corp. 100 days to give a clock widget :)" -- @mischat

"BBC claims it will take them 100 days to fix a clock on their website #jobopportunities" -- @roytries

This reaction is pretty common from enhancement owners when they get any seemingly high estimate for what's perceived to be a simple requirement; but is this reaction reasonable?

Analysis

Those who've been in professional software development, particularly of web applications, can probably see how a requirement of 'show a clock' - in fact, a factually accurate clock - could balloon.

Let's look at the crux of the requirement that will have been estimated:

Show a clock on the homepage that is 'factually accurate' for the user's current location, without relying on any features of the user's local configuration.

When looking at requirements, I like to find the edges of the scope; to look into the corner cases and see if an internally consistent approach can be developed. My train of thought here goes:

• We can't use the user's computer's local time, so we will have to use the server time.
  • The server time is - probably - GMT, UTC or UK local time (GMT, or BST in daylight savings). This is also excluding the complexities of the CDN and the multitude of servers involved (although with NTP they should all have accurate time).
  • Showing the user time in the UK is not acceptable for our international users: it'd be a regression as they previously saw their local time (probably).
  • We cannot use the user's computer's local timezone as that would violate the original accuracy complaint.
  • The BBC already uses geo-IP services for localisation. Will this be accurate enough? Our first item requiring further research/prototyping.
• We'll probably have to update it: the current one updates, and viewers don't see a static clock on the News Channel, so would expect to see it update on the web.
  • Can we send one initial time with the server, and update it with JavaScript?
  • Does that violate the original accuracy complaint if the user's computer can't deliver a timer exactly every 1.0s? (This is known as clock skew)
  • If so, some form of COMET/push of time will be required. Do we want this handled by the existing servers/CDN?
• How accurate does the time need to be?
  • Does it need to take into account network latencies? (Not insignificant on 3G, for example)
  • What about browser rendering time, if the page started at 11:59:59.900 and the user is on an older/slower computer?

Some of these questions need to be tackled before development (some come to mind to be discarded), as well as sign-off for a functional change to something as high profile as the BBC's homepage. There's then testing in all the different scenarios and browsers which could crop up, deployment (ideally staged, A/B tested), and some time will need to be set aside to deal with the inevitable fact that a complex development like this is inevitably going to find edge cases in the real world - no matter how well you think you've tested.

I'm not sure I'd've got to the 100 days estimate, but I can see it not being far off. Mark Stickley's In Defence of the BBC and its Clock makes similar points and brings a BBC focus to it as well.

Initial success in porting Harmattan/Symbian QML app to BlackBerry

This is the first post in a new BlackBerry category in my blog. Having attended the "BlackBerry 10 Dev Jam" in London last week, BB10 looks very interesting - and a spiritual successor to MeeGo 1.2 Harmattan, i.e. the Nokia N9.

It's particularly interesting as BlackBerry have created their own Qt/QML-based environment, called Cascades.

However, I've got an existing app, Bedside which is almost pure QML. Could I get it running? More detailed instructions will come later, but here's how I got to where I am:

1. Install the BlackBerry 10 Native SDK and developer environment.
2. Create a new BlackBerry Cascades C++ project, although we're going to use it for "plain" Qt (as described in this Chinese blog post).
3. Ensure you add <env var="QT_QPA_FONTDIR" value="/usr/lib/qt4/lib/fonts" /> to bar-descriptor.xml.
4. Copy qmlapplicationviewer.{cpp,h} from the existing project into APP/src/.
5. Put your QML resources in APP/assets/ (note you can't use asset://... URLs within the QML files, as you can with Cascades).
6. Replace main.cpp with a simplified version from your other project, for example:

#include <QtGui/QApplication>
#include <QtDeclarative>
#include "qmlapplicationviewer.h"

int main(int argc, char **argv) {
  QApplication app(argc, argv);
  QmlApplicationViewer viewer;
  viewer.setMainQmlFile("app/native/assets/main.qml");
  viewer.showFullScreen();
  return app.exec();
}

In particular, note the path to the main-QML-file.

And here's the initial version of Bedside (with no screensaver interaction yet) running on the BlackBerry 10 Dev Alpha:

UPDATE: With a bit more work, I've got a single source tree working: now I can deploy to Symbian, Maemo, Harmattan or BlackBerry 10 (using Qt SDK for the first three, and BB10 Native SDK for the latter).

Instructions are in this forum post.

Avoiding jet lag using continuous clock change

These days I'm often travelling long distances; whether it's to Asia or Detroit with work; or San Francisco for the MeeGo and JavaOne Conferences.

Ten hour flights are rarely fun; but when combined with a ten hour time difference? The jet lag can destroy you.

However, I trust a clock when I see it. So if I can convince myself that the time isn't changing in one big jump, jet lag is less of an issue. I used to do this with my watch: every two hours on a ten hour flight with an eight hour time difference: move my watch forward two hours. By speeding up, or slowing down time, I find it excellent for transitioning gradually to my destination timezone.

My N9's standby screen provides an opportunity to do this automatically: every time I glance at my phone on the flight, it could show me the right "transient" time.

I prototyped it with a spreadsheet (download), for a recent trip to Korea, to see how effective it would be before writing an app:

 

To try it out, first off, enter the local departure and arrival times; and the timezone difference:

If travelling eastwards, the time difference will be positive. If travelling westwards, it will be negative.

A shell script will then be shown in column E. Copy this column and paste it into a text editor. Copy the resulting script to your UNIX-based mobile device (N9, N950, N900, N8x0, jailbroken iPad).

On a Harmattan device, the script needs to be run in develsh:

~ $ develsh outbound.sh
...

On everything else it needs to be run as root:

Jaffas-iPad:~ mobile$ su -
Password:
Jaffas-Ipad:~ root# sh outbound.sh
...

If run with screen or nohup, you shouldn't even need to keep the terminal open.

NEXT STEPS

Obviously the next step is an app. Is it something you'd be interested in? Is there a nice Qt API for changing the time? Are there Qt APIs for looking up timezones, and setting the device's timezone?

Thanks to eipi for allowing me to use MaeFlight's icon in this post. Also published on Nokia Developer blogs

Colour operator logos on N9 lock screen

Nick Larsson (aka frals) has posted an article on adding a small (120x120px) logo to your N9 lock screen.

The N9 has a PenTile AMOLED screen, but is configured to avoid the colour fringing problems that affected the Android-based Nexus One. However, when the lock screen is displayed, certain bit patterns produce colours:

John Hutchison's Generating false colour images on the Nexus One using only grayscale pixels contains source code and examples.

The above photo was created by taking a 120x120px cut from the example rainbow image and setting it as the logo:

The same section, viewed on a Nexus One looks like:

As you can see, the colour mapping isn't the same (meaning new reference images need to be generated). However, you'll see it is possible to have colour logos on the lockscreen. Hopefully someone will take it forward, perhaps Nick can update his tool to do colour mapping; or someone can post the reference images so that the Java source code from Luke Hutchison can work.

MeeGo Conference keynote: how it should've been done

The first official day of the MeeGo Spring conference started with a two-hour keynote by Jim Zemlin, Executive Director of the Linux Foundation. While MeeGo is a Linux Foundation project, nobody from the Linux Foundation is formally involved on a day-to-day basis in the management and leadership of the project, which is being left to Intel (and, previously, Nokia). Because of this, Mr. Zemlin stands in as the Linux Foundation's public face for MeeGo.

It did not bode well when the advertised title of the talk, The Future of MeeGo Starts Now was changed to Monday Morning with MeeGo. This event was the opportunity for the MeeGo Project to showcase, and celebrate, last week's 1.2 release (including the N900 Developer Edition). Instead, we got Jim Zemlin talking about the advantages of Linux and open source without connecting the concepts to the MeeGo project and how MeeGo adds value compared with other Linux-based, open source mobile OSes (e.g. Android).

A number of guests joined Zemlin on stage, with Imad Sousou (MeeGo's Technical Steering Group's sole member) and long-time Maemo and MeeGo contributor Robin Burchell being the highlights. However, the main thrust of the speech was that mobile Linux, and open source, are here now - and will increase in future. The issue lies in that the supporting graphs and data that were shared during the keynote were all based on Android's adoption, with hardly a mention of MeeGo. Nokia's groundbreaking work with consumer mobile Linux devices, which led to the creation of MeeGo, was not mentioned at all.

Here lies the problem with MeeGo being a Linux Foundation project: they aren't interested, or invested, in the success of MeeGo - just Linux in general. Therefore, they'll support anything which furthers that goal, including webOS and Android in the mobile space. This was reflected in the keynote: since the Android is already so successful (and its market-share is growing) it's not in LF's interests to try and fragment the mobile Linux landscape.

Announcing new devices, or freebies for attendees, isn't necessary. However, I did expect the MeeGo Conference Keynote to address the challenges facing MeeGo now; particularly since February 11th there is not a mass-market consumer electronics vendor onboard as a strategic partner. Celebrating the work that has been done to date is necessary for the community psyche. Outlining the next steps, including a roadmap, is integral for the development ecosystem. None of these things were done, and it left a pall over the entire conference.

Personally, I attended the conference believing that Nokia's upcoming MeeGo-compatible Harmattan OS had to work to try and get itself integrated into the MeeGo ecosystem in order to benefit from the growth that MeeGo was going to enjoy. I came away from the conference believing that MeeGo needs Harmattan a lot more than Harmattan needs MeeGo.

MeeGo needs fresh blood; a sentiment shared by others. The "#jaffa4tsg" hashtag on Twitter started to be used after Imad responded to my question about expanding the TSG (Technical Steering Group) beyond a single member by saying that anyone was welcome to put themselves forward. A surprising number of people I very much respect said that my flippant "I'll do it" was an excellent idea, with me "getting MeeGo". My professional experience in the IT industry, as well as my wide experience and standing in the community are also strong reasons to be involved.

Assuming this isn't an entirely silly idea - although there is no documented process by which people can join the TSG - here's how I think we should have run the keynote (keeping the two hour running time, and abiding by the rumour that politics prevented Nokia talking about Harmattan & announcing the awaited developer programme):

1. Welcome, including rerun of the "MeeGo on all your screens" video from Dublin (10 mins)

2. What've we achieved in the last six months? (30 mins)

   • MeeGo 1.2 tablet demo
   • MeeGo 1.2 demo on N900 Developer Edition ("mass-market consumer hardware, capable of running MeeGo")
   • Overview of all the manufacturers who have released, or committed to releasing, MeeGo hardware (including Nokia)
   • Announcements about Linpus, Red Flag Software, 4tiitoo AG and China Standard Software Company (C2SC) updating to MeeGo 1.2 base

3. Why MeeGo can succeed in a crowded market (35 mins)

   • 20 years of Linux video
   • Mobile OS ecosystem (Danielle Levitis, IDC)
   • Some numbers from Dawn's community metrics about growth and activity of community
   • The potential of IVI (Tsuguo Nobe, Chief Service Architect, Nissan)
   • Time to market (4tiitoo and Amino)
4. Organisational and governance changes, to ensure we do succeed in the next stage of growth (10 mins)

5. What next for MeeGo (20 mins)

   • Roadmap for MeeGo 1.3 and call to action for faster innovation (Arjan van der Ven)
   • MeeGo 1.4 and beyond
6. Soundbites video from day 0 (2 mins)
7. Audience Q&A (13 mins)

Notice here that there's no wishful thinking, everything above (apart from governance changes) was either announced during the conference, put out in a press release or already known. But it is MeeGo-focused, which - in my humble opinion - the opening keynote of a MeeGo conference should be.

Cross-platform Qt dev: deploying to Symbian

I've gone beyond the playing with QML stage and now want to port my first Maemo 5 application, Attitude, to Qt Quick; with the aim of having it run on Maemo, Symbian, MeeGo and Android.

Development environment

I'm using the Qt SDK 1.1 beta on Ubuntu 10.10. I'll deal with developing with this in another post (Eclipse keybindings, the combination of graphical and source editing (and the limitations therein), issues to bear in mind). Here I want to deal with deployment. Qt Creator offers a number of targets:

• Desktop (not relevant to this app)
• Maemo
• Simulator
• Remote compiler

I chose the last three. On Linux, there is no native support for deploying or compiling for Symbian. Compiling can be dealt with by the "remote compiler", but what about deploying?

I can, now, to the following; all from within Qt Creator:

• Compile Qt applications and get a signed SIS file for installation
• Install the SIS file on to a USB-connected N8
• Start the application and get its console output back in the IDE.

Configuring the remote compiler

1. Get a Forum Nokia account, if you do not have one.
2. Install runonphone.
3. Download this script: runonphone.wrap, and put it on your PATH (make sure it's executable).

4. In Qt Creator, select Tools > Options... > Projects > Remote compiler and authenticate with your Forum Nokia details:

   
   
   

5. Open your project, and select Projects > Remote Compiler > Build. Ensure Signed is checked.

   
   
   

6. Switch to the Run tab and create a new deployment and run configuration.

   • Command: runonphone.wrap
   • Working directory: $BUILDDIR
   • Arguments: either install (for deploy) or run.
   
   
   

Configuring the device

1. Go to <QT_SDK>/Symbian/sis/Symbian^3.
2. Send the SIS files under Qt/4.7.2, QtMobility/1.1.0 and TRK to your phone (e.g. via Bluetooth) and install via launching them.
3. Go to the main launcher menu and launch RnD Tools > TRK.
4. Under Options > Settings ensure USB is set as the connection method.
5. Connect your Symbian phone via a USB cable.
6. Select Options > Connect.

Then, when you deploy and run in Qt Creator the SIS file should be sent over the usbserial connection and launched on the device.

Unfortunately, if there's a problem you can sometimes end up in a state where you need to kill -9 the processes blocking the port. It also doesn't seem to like working on /dev/ttyUSB1, only /dev/ttyUSB0 - but these could all be interrelated problems. Improvements to the script very welcome!

We go to MeeGo

Please forgive the cheesy title :-) As everyone wrapping up the conference has said, it was a great place; well organised and a fantastic atmosphere. Here are some of my bullet point thoughts:

• Venue was good, although visibility in the keynotes was a little poor. Doug Fisher's reveal of "everyone" getting an IdeaPad was spoiled by it only showing on half the monitors (the other half showing slides).
• Hotels were close to the venue, which was very handy. Unfortunately, a bit far out of the city centre, but cabs and buses to the touristy Temple Bar area were fine.
• Nokia and Intel are both very committed.
• People like Nomovok are doing interesting things behind the scenes.
• The Hacker Lounges, with table tennis, DVD player, Wii, Xbox, free beer and snacks were fantastic.
• IdeaPad is nice hardware. No-one's done a good netbook/tablet hybrid OS yet, AFAIK.
• It was great to catch up with old friends (Ryan, Tim, Graham, Stephen, David, Carsten, Niels, Quim, Gary, Peter, Ronan, Randy, Dave, and so so many more)
• It was great to people I've only spoken to online (Dawn and Kathy amongst others)
• Lots of new folk met: Chani, Odin, Julien, Morten, ...
• Amy Leeland, Dawn Foster, Quim Gil, Angela Brown and anyone else involved did a wonderful job. A definite successor to the Maemo Summits.

One thing which struck me, which hasn't been dealt with elsewhere (AFAICT), is the obvious struggles MeeGo is having being an "open" project. For example, during the Compliance talk, I asked Mark Skarpness where the discussions on the specification were happening; as we seemed to get new draft, with a request for comments on a regular basis; where are the discussions happening as to what goes in to those drafts? "meego-dev" was the answer, one I'm not quite sure I believe. On the plus side, my suggestion of an "Extras/Surrounds Profile" seemed like it might have some traction in solving the third-party-dependencies problem.

Similarly, in the past few weeks, the MeeGo Summit in Oulu, Finland - at the end of May - is being announced and planned in the open; and discussed on meego-community. However, at the conference, the MeeGo Community Office announced that there would now be two MeeGo conferences a year, with the next being in San Francisco at the end of the May: the week before the Oulu summit. This is not something the Community Office has pulled out of thin air in the middle of the conference: but where was the discussion ahead of time? More back channel collaboration, no doubt. Would the Oulu folks have chosen the same dates if it was known that there was an official conference being discussed for the same timeframe?

As explained in the keynotes, MeeGo's openness to OEMs, carriers and application developers is one of the key differentiating factors which is necessary for MeeGo to succeed in a market where iOS and Android have all the momentum. However, if MeeGo is to have that same openness from a community point-of-view, these kind of things have to be addressed as well.

However, I've come away feeling even more positive about MeeGo than I did before. Chats with Ville, Attila, lbt, Ronan and Peter show that Nokia (at least) gets what the Harmattan device means and the developer story they have to tell. Qt Creator 2.1, with Qt Quick, looks like a really promising IDE for both developers and designers to collaborate.

Join MWKN hacking - right *now*

At the MeeGo Conference in Dublin? Want to come and see how MWKN is put together every Sunday evening?

Come along to the D4 Ballsbridge, following signs for "MeeGo Conference 2010 Early Bird Event" and we're in the bar next to the ballroom.

You might want to bring a beer from the Dubliner, as the bar here's not (yet?) open.

MWKN issue creation @ MeeGo Conference, Sunday evening

As Ryan and I - editors of MWKN - will be at the MeeGo Conference on Sunday evening, we'll try and find some space to get together to put together the issue. We'd love to have some help!

What's MWKN?

M* Weekly News is a weekly news digest from the MeeGo/Maemo worlds; inspired by LWN and Wine Weekly News.

Throughout the week, contributors ping over links and short titles to the @mwkn account on Twitter. These then get expanded with quotes, de-duplicated etc. on a Sunday evening for the issue to be published on Monday morning.

The idea is that the community is far too large for any one person to know everything going on, so we can crowdsource the interesting bits which are happening on IRC, the mailing lists, the fora, elsewhere on the Internet etc.

Want to get involved?

Getting involved as a contributor, or an editor (to help with putting the issue together), couldn't be easier; and we'd love to have more people involved.

Please feel free to get involved ahead of time or - if you're going to be around in Dublin on Sunday evening - let me know, and you can either come along and help edit the issue; give us moral support or just get a flavour of what it is we do.

Here and Now: what's on near you now

Nokia's N8, a Symbian^3 device, comes with a service called Here and Now. This reads the cell tower information you're currently connected to and opens a web page detailing the current events (cinema listings and weather, for example) near you. I've done a quick port to Maemo 5 and the N900.

Once installed, you can launch it like any other application:

Without using a GPS, it sends your approximate position to Nokia's servers and shows you what's currently going on:

Council election time again

Voting has now opened for the next Maemo Community Council and, once again, I'm standing.

Last year I won, and the council chose me as their chair (hence the quietness of this blog compared with the Council blog, or even MWKN).

Please vote, the Council this next term will be very important in setting the tone of maemo.org, and the way the Maemo community can work with (and, where desired, transition to) the MeeGo community.

You can read my declaration, my response to EIPI's set of questions covering numerous topics. Then, don't forget to vote. Contact Dave Neary if you have not received your voting token.