Maemo People

In a brief break from Hermes-related Maemo work, I was inspired by Manfred Weiss' MyMenu to create an auto-organising menu application for the N900:

Catorise organises the application menu to have top-levels corresponding to the sections in Application Manager. Features:

• Uses the section icons from the current theme, falling back to the default theme if none available.
• Determines an application's section from the same information the packager used when uploading it to Extras.
• Keeps track of application installs/uninstalls.
• Entirely non-destructive: remove the package and everything goes back to how it was before.
• "All" and "Other" sections, just as in the App Manager, to provide additional access routes.

So, with Catorise the section you find an application's icon is the same you used to install it!

It is currently in Extras-devel. This should, therefore, only be tested by people who are willing to suffer potential data loss, hair loss and the eating of babies.

It's largely feature complete, however there are some known problems/future developments:

• Applications installed from Ovi will go into the "Other" section, due to the way Ovi on Maemo has been designed. I've some thoughts on how to work around this, though.
• Changing the theme will only update the icons on the next application install/removal.
• A quick GUI editor could be created to manipulate /opt/catorise/menu which is a simple text file cache to speed-up rebuilding. This would allow the user to shuffle the apps to best suit their use cases.

I've been discussing this idea with a few key contributors over the past few days to make sure it's realistic and feasible. We've polished it and would like to ask for volunteers for a new Maemo Weekly News digest.

Workload: little to some.
Benefits: glory.

Read on for more info...

Background

There are a lot of facets to the Maemo community, whether it's Bugzilla, maemo-developers, #maemo, Planet, Talk or Brainstorm. With the N900 and Maemo 5, there's been a noticeable increase in traffic in all these areas.

There have been suggestions of Maemo magazines before, but they've fallen over because:

1. The people involved haven't been integrated into the community.


2. They've been a lot of work to create.


3. They tried to move away from maemo.org/news/

Similarly, there are blogs (like Reggie's Maemo Talk) which highlight key important things; but some of them also suffer from the same problems above and none yet go into the level of detail I'd like to see.

With the increase in volume, and limits on my own time, I'm finding it harder to be aware of all the things going on. In particular, little asides and so on on talk which are key to the community, but buried in a thread. The old complaint of "too much happening outside of talk.maemo.org" is now reversed, IMHO, but the SNR is too low to follow "New Posts" religiously and develop software at the same time.

Idea

A weekly news digest of key useful/informative/interesting/insightful news from all Maemo news sources. Similar in style and approach to Linux Weekly News.

This is, in many ways, a continuation of Ryan's "Community Highlights" but doing less work, being more encompassing and more repeatable.

This is NOT an attempt to aggregate ALL Maemo-related news, but provide a selection of highlights during the week; of interest to those who are involved in the platform and the community, but without the time to follow enough of the conversations in all the places to find the ones interesting to them. By acting as a filter, more people will be able to be involved in the things which interest them, resulting in an increase of higher quality submissions for members of the community who might not be heard from as much.

Implementation

The key to its success is to produce something which is useful, integrated and deterministic; but without being a massive resource hog.

Produced weekly, every week, with a series of sections - probably similar to those on tmo. Something like:

• Front page
• Applications
• Development
• Community
• Devices
• Maemo in the Wild
• ...

To gather the news, a series of sub-editors/contributors would have access to a Twitter account (@maemoweeklynews, say). The posts to this feed would consist of the section, a few keywords and a link to the content (thread, post, email message, blog) which triggered it. For example, recently this may include:

• Applications - wazd helping qwerty12 on Transmission: http://s56.radikal.ru/i152/0911/34/a388e13890a0.png
• Devices - Release firmware available to download: http://flors.wordpress.com/2009/11/16/maemo-5-final-release-updated-sdk-and-firmware/

Suggestions on content could be directed at it from people's own Twitter accounts. The sub-editors would then be able to pick and choose from these if it's something they'd missed.

As each issue is being pulled together, one or more sub-editors would then review the posts to that Twitter feed for their sections and flesh it out with a longer paragraph/quote. Full-blown stories would also be possible, but I imagine that being a rarity (if ever). There would then be an overall editor(s) making sure there's no duplication and also including things from maemo.org/downloads/ (top 10 apps, and new apps this week) and the bug jars (top 10 activity, probably).

The completed digest would then be posted to a site and syndicated to Planet.

Hopefully this shouldn't be too much work; and sub-editors/contributors would be able to post to the feed during their daily review of their slice of the community.

To collect the sub-editors, I'd suggest a recruitment & screening process of the form "what 3 would you have done for last week?" See more details below.

Getting Involved

I'm now looking for:

1. CONTRIBUTORS: long-standing members of the community to volunteer to highlight content they see during their Maemo day. This could be whilst sat on IRC, reading the mailing lists, watching maemo.org/news/, contributing on Brainstorm or reading Talk. The only extra work you'd have to do was use your favourite Twitter client to post links you thought should be in the digest.

   Approx. number of positions: 20-30




2. SUB-EDITORS: contributors who are also willing to flesh out the links each week by selecting a representative quote. I will be ensuring we have the tools in place to make this as easy as possible.

   Approx. number of positions: 5-10




3. EDITORS: the people with ultimately responsibility. The sub-editors who make sure the whole thing is consistent.

   Approx. number of positions: 2-4

As I want to start it small (it can always grow once we work out the details a bit better and see how it goes), anyone who'd like to be involved can reply to this (it'll be on maemo-community, my blog and talk.maemo.org) with:

• maemo.org username
• Position wanted (contributor/sub-editor/editor)
• Channels you follow
• Preferred section(s) if sub-editor (feel free to make up a new one)
• One/two sentence bio.
• Two or three links you'd've posted in the last 2 weeks.

This is an opportunity to help collaborate and facilitate spreading Maemo news; if you're a long-time contributor to the platform, your insights will be invaluable. If you're a relative newcomer, looking for a way to contribute, this is your chance!

Marko Mattila has published nice overview of Maemo Image Editor project which is part of Maemo 6 development, opened under Qt-GPLv3-LGPLv2.1 licensing triplet at Maemo Summit 2009. Maemo Image Editor is not an editor application in itself, it is set of libraries to provide basis for mobile image processing. History of editing is preserved and crash recovery is provided as part of image editing infrastructure. The project also aims to allow manipulations of huge images in memory constrained environments, like N900 and future devices.

At Maemo Summit 2009 I half-jokingly presented Maemo Image Editor's goal to scale beyond 100 megapixel. 100 megapixel number looks huge but only for yesterday's view. If we would look into five years' perspective, 100 megapixel are just five photos made with Canon Eos 1Ds Mark III stitched together. This is today's technology. If we look into 360-degree panorama even with N900's 5 megapixel camera, we would probably need to take about 8-10 of those, meaning processing of 40-50 megapixels. Panorama stitching is one though quite popular example, according to talk.maemo.org discussions; there are many other nice applications for high resolution processing as well. What's lacking usually, a careful memory and I/O handling.

Maemo Image Editor aims to get memory and I/O into a reasonable control. Even with this favorite example of panorama stitching you would not need to keep whole 50 megapixels image in memory. When overlapping features from successive photos are searched, only narrow parts affected, making it possible to save in memory use at expense of I/O operations. Of course, direct access to photo regions helps enormously in this case, but the way photos represented on disk is limiting us in many cases. For example, JPEG image compression schema does not allow to address region of interest (RoI) directly, you would need to work out mapping between compressed mathematical representation of an image and actual pixel positions, and store that information somewhere. Additional indexing might allow you to get faster loading but existing free software image-handling libraries do not support it (yet).

And this is just a tip of an iceberg. Traditional image processing APIs are built around idea that your application is interested in loading full image in memory. While this might be true for certain applications, it is far from reality for majority of cases. Unless I'm doing real image processing, chances are high that I'm actually interested in scaled down version -- for example, using it as an icon (thumbnail) or fitting it to screen size, or even just an application's window size. This is especially true for cataloging applications -- be it galleries of images or some sort of media library where images are serving as "previews" of videos and audio collections ("album art").

These applications would benefit from exposing their intent to use picture to an image loading API. If intent is received, image loading API could optimize for it, by looking into a specialized cache for a thumbnail or a preview, instead of dealing directly with multi-megapixel image. This is something we are trying to get working with updates to thumbnailing D-BUS API that Philip Van Hoof and Jannis Pohlmann are taking care of.

Proper image processing is a nice and complex puzzle. Solving it is a great engineering challenge, and as any puzzle would require multiple steps. Qt image loading API (QImageIOReader) is a nice approximation of what is needed on the low level from image loaders. Implementation of that API for common image formats like JPEG or PNG is asking for improvements, especially given that almost none of features exposed in API (Region of Interest access, dynamic rescaling, etc) are implemented for all formats and/or optimally. Dynamic splitting of an image to smaller blocks (tiles) which are managed together and fetched/stored behind the scenes to save memory is absent completely. Partitioning of tiles, effective for image filters being applied, is asking for implementation. GEGL project has shown that many of these goals are possible to achieve and may be at some point Maemo Image Editor would have a compatibility layer with GEGL to allow sharing filters and enriching free software.

Unlike Navicore/Wayfinder on previous Maemo devices, Ovi Maps on the N900 downloads maps on demand. This is obviously a problem if you're going somewhere abroad and don't want to pay extortionate data roaming charges.

Fortunately, S60 Ovi Maps users also have the same problem, and the solution is straightforward:

1. Scroll down the above URL and download the maps for the countries you are interested in. Obviously skip the instructions about downloading Ovi Maps - the N900 has Ovi Maps already installed!



2. Unzip the maps into cities/diskcache on the big VFAT partition (mounted under MyDocs) on your N900.

3. That's it!

Some of the files you may already have, I've chosen to overwrite them; YMMV.

However, as far as I can tell, searching for locations still requires a network connection :-(

As those of you who read maemo-community might know, I've decided not to run for the council this time.

I'm really proud of being a part of the first two councils, and the level of trust Nokia placed in us with the recruitment of the debmaster; chairing the sprint meetings for the gang-of-four; the decisions over the summit and inviting us to the launch of the N900 at Nokia World.

My enthusiasm for Maemo is not diminished; indeed, with the launch of the N900, I'm as excited now as I was waiting for the launch of the 770 back in November 2005. However, after a year on the council, I'm now looking forward to six months as "just" a normal community member. I've not come to this decision easily, and I'm very happy to have had such warm words of encouragement. My reasons are two-fold:

1. There are many other members of the community who should have a chance to represent us. In particular, I'm very happy that Stephen (sjgadsby), Valério (VDVsx) and Graham (gcobb) have chosen to accept my nomination of them. The fact they're joined by the likes of Alan Bruce (qole), Gary Birkett (lcuk) and Jay Carter (zerojay) - and others - is even better.


2. The vitriol and nastiness spewed by a very vocal, but tiny, minority of people on talk.maemo.org - especially regarding the transition of internettablettalk.com to talk.maemo.org - took a lot of the fun away. Given the massive investment of time my role as chair required, taking the fun away removed one of the main motivations for me.

I still plan on being an active (and vocal) community member both as a developer, a community evangelist and as a user. I hope that if you would have voted for me, you consider voting for one of the excellent candidates we have standing (and we have many). In particular, Stephen, Valério and Graham have all been long term contributors in many different ways and are tolerant, helpful people. I will struggle to cast my single transferable vote for them, Gary, Alan and Jay.

However whomever you vote for, please do vote (once you receive your voting tokens)! I think that the Community Council has been far more effective than I ever imagined it could be when I suggested it back in 2008 and I look forward to seeing where this community will go in the next six months