Maemo People

The election period has started for the next Maemo Community Council election and we have a number of excellent candidates, including - even if I do say so myself - me ;-)

Before I decided to run, I asked each candidate a series of questions - the answers we've given are linked to from the candidate summary page. I'd also encourage other community members to come up with questions for the candidates.

My full candidacy announcement is in the thread. The main point is that the last six months, having stepped back from the council, have given me a new perspective. The biggest issue I've seen is one of communication and clear facilitation. We need to reduce the overhead and streamline community action. Therefore, if elected, I will push for:

• A clear cooperation with the growing MeeGo community through MeeGo's Community Working Group and develop a transition plan to ensure the level of collaboration the council has with Nokia isn't lost in the new world.
• A Moblin/Maemo/MeeGo summit which looks to the present as well as to the future.

• Appropriate support and resources for existing device owners as Nokia transition to MeeGo. Exactly what form this will take will depend on whether running MeeGo is a day-to-day reality for N8x0 and N900 users:

  1. If MeeGo provides a comparable experience, without any loss of functionality, the resources around Maemo can be slowly redirected.

  2. However, if MeeGo for existing devices is - at best - of developer interest only, the existing Maemo community must continue, and must continue to provide support, help and resources to Maemo users.

  Mer^2 should help with the final point, and I'm proud to have been on the council which approached Nokia requesting a distmaster role; and suggesting that Carsten (Stskeeps) was the right man for the job.

• Increasing the visibility of the maemo.org sprint process and reducing the burden on volunteers. Niels Breet (X-Fade) being made the maemo.org team leader will help here. Having been involved in the running of an agile project for over 2 years, I believe:

  • Niels should chair the sprint meeting.
  • The meeting participants should be responsible for setting their priorities and what will be included.
  • Input should be provided by Nokia (Tero Kojo) and the community (the Council chair) on their issues and priorities before the meeting which should be taken into account within the prioritisation.

  This will reduce the workload for the volunteers on the council, increase the ownership of the tasks and provide greater accountability of the paid contributors.

• A summary table listing the high-level issues facing the community and who on the council will act as a point of contact for them. An example for the current council could be:

         Extras QA process         VDVsx
         Optification              gcobb
         Community outreach        Texrat
  

• Support for Randall Arnold's community outreach programme, which is trying to grow the Maemo community rather than just the Maemo platform. With the launch of the Ovi store for Maemo, much focus is given to that rather than the community provisions such as Extras.
• Empowering of community members to lead initiatives such as Google Summer of Code, conference attendance etc.
• A monetisation/donation framework for community-provided downloads.

Whether you vote for me, or someone else, I'd encourage you to vote! The transition from Maemo to MeeGo means the community's representatives to Nokia are more important than ever. Voting is open to anyone with a maemo.org account which is older than 3 months, and has accrued more than 10 karma points.

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 :-(