The results of the first programming competition for Openmoko phones

April 5, 2009 in Openmoko | 6 comments

http://openclipart.org/media/files/ben/9651

http://openclipart.org/media/files/ben/9651

We announced a month ago the first programming competition for Openmoko phones. Now it’s time to publish the results!

Three applications participated in the competition: Mokotunes, Neoreader and Gorshplayer. It looks like all projects were more or less one-man shows, this is a bit sad, as so much more could have been accomplished if there were teams. Also, no project is actually trying to really integrate into any of the distributions (i.e. prohibiting suspend while playing, or reading from a common media storage subsystem) — this might be too much given the time constraints, but still we’d love to see any attempts of doing that. But however we’re quite happy to see this many projects participating that have a huge potential to come out as great podcast players.

The source codes and installation instructions can be found at here. The reviews below are written by the jury: Michael ‘Mickey’ Lauer, Marco ‘Treviño’ Trevisan, Aapo Rantalainen and Risto H. Kurppa.

Mokotunes

Mokotunes, written for OM2008.12 by Wilder Mokotunescan be considered just a little more than a nice mockup just now since most part of the core functionalities are not implemented yet. In it’s current state it only shows a kind of “demo” playlist with some buttons for controlling the media reproduction. It looks like time run out for this project — they started with a good software design, but not enough rapid prototyping.

GUI
From the GUI point of view it’s hard to do a consideration. But the interface seems a little slow. Also if it includes only few elements in its list, the scrolling is not so smooth (maybe due to the pixmaps used in the theme!?) so we don’t expect it to be better in a real scenario.

PODCAST MANAGEMENT
No signs visible yet how the management of the podcast feeds and of the downloads is going to be like so it’s too early to comment on this.

AUDIO PLAYER
It’s still too early to say what kind of a player this will be like..

CODE
The code, that mostly presents some skeleton functions, shows that it is a very well written/structured C++/EFL project that uses edje for designing the interface while Gstreamer to play the media (actually impossible due to the missing interface for retrieving the data, but the code for playing seems to be all there!).

FUTURE
Could get pretty nice, if developed further. It could also serve as a good example for integrating EFL + GStreamer in a C++ project. It’s still something of embryonal but the core it already has seems good, and it could be extended to get something of functional one day.

CONCLUSION
Good start, nice code, but still very immature.

Developer: Wilder <blackinblackATlist-ru>
Files & installation instructions

Gorshplayer

GorshplayerDeveloped for Debian by Chistophe M, it was the only project sent that was working “by default”. Basically the author added a new podcast media importer feature to the existent Neoqplayer/Gorshplayer code. It’s actually pretty polished and a nice app. It doesn’t seem to be written for the Neo though, it’s too slow and the UI doesn’t really fit the device. On a Nokia tablet, it could rock.

It has a nice colourful layout and had about all functionality included we were looking for: podcast player & management GUI & downloading, playing podcast episodes and local media files with playlists etc. And it installs nice now when Aapo created the .deb file.

GUI
The player view is indeed pretty with a colourful background but the usability isn’t so good for two reasons: first of all it is not so finger usable (yes, the buttons are big enough, but there’s no finger scrolling, and double-clicking is hard! Not to mention that the window is too big to be used with a shelf, so it’s made for working in fullscreen), then to add a podcast an user should go into preferences, paste an URL, go in the podcasts list, load a podcast, double-click an item to download, go back to the main window where he can select the media to reproduce. All this is quite annoying. It’s nice that one can use the app to config the file folders.

In the play view the battery display is good if Gorshplayer is used in full screen mode. The display showing the play time would be a great addition.

PODCAST MANAGEMENT
Fetching episode lists works OK though the app doesn’t remember the episodes on the next run without clicking the fetch button. It’s nice that there’s a download progress bar visible, maybe it could be added in the same view with the episode listing?

AUDIO PLAYER
Is able to remember the playlist content, has volume control slider and ‘jump back’ button that allows you to jump back the number of seconds set in the preferences view. For some reason the player has very high cpu requirements -> up to 100% which means that it eventually stops playing the files – only OGG files worked this time.

CODE
The player is written in C++/Qt and that is a very good choice in general, but unfortunately not for the openmoko applications yet. In fact this toolkit doesn’t support by default some finger-friendly features that could improve a lot the usability, and from the user point of view, it is not so easy to be installed in the most part of the distros available natively for the Openmoko devices (also if it works, I’ve ran it also in Om2008). Of course this is not a developer fault, and this player is a very good choice for distros like Debian. Code-wise, it’s ok. The classes are reasonably layed out and seperated. It could have used more of the UI designer, though.

POTENTIAL
It has also some potential and nice features but needs some work to be done. Not new features but.. just some things done better. For example the 70-90% CPU is too high, wonder if it would need a newbackend/something to work ok. We also hope that it will improve making the podcast reproduction a little bit more friendly.

CONCLUSION
Good player, well written, works, but not focused for the podcast playing, not so finger usable, not yet ready for any “telephonic” distro (SHR/OM).

Developer: Christophe M <meumeu1402ATgmail-com>
Files and installation instructions
Gorshplayer website

NeoReader

Neoreader was originally written for SHR by Thomas Roth and Mikael Voss. Neoreader We had to struggle hard to be able to run it: when we received the code it wasn’t compilable for an Openmoko phone (no problems on PC, instead), however playing a little with the toolchain we got an arm binary. Unfortunately everywhere we’d run this software, it simply crashed when trying to fetch the podcast media. So, if it should be judged only based on its basic functionality, it simply doesn’t work. However there was some idea behind the interface, so after some fixing we got it working.. We were very close to disqualify NeoReader but thanks to Marco, we were able to review it.

But now that we have it up&running: The GUI is unfinished, the frontend/backend cooperation suffers, the app is very unfinished and it was a pain to install. But on the other hand the code impresses and it uses only very little resources, it’s not a problem to use other apps at the same time in 2008.12 when playing a podcast with NeoReader.

GUI
There’s no visual feedback telling that an episode is downloaded but an icon shows downloaded episodes, nice! The buttons are quite big so it’s usable with fingers.

PODCAST MANAGEMENT
Trying to add a new podcast crashes the player (click add a podcast feed -> try to type something -> nothing happens -> click ‘Add Feed’ -> crash.) -> not possible to add a new podcast at the moment, also not possible to remove a feed?

AUDIO PLAYER
Neoreader is only able to play files from podcast feeds. The current version can’t play local music/audiobook files which is a big minus. It has nice 5/30s ff/rew buttons that work very fast. The play gui also has buttons to change the speed of playback to faster/slower. The idea is great, a spoken podcast can be listened much faster than 100% speed -> more efficient podcast listening :) Speedup % would be nice to see as well as the file play time. Volume control slider would be a nice addition, as well as some visual feedback to tell if an file is being played or not.

CODE
Thanks to using ELM, this could be the only app that would really work well on the Neo, if developed further.

Looking at it a little more deeply, we found that it has a kind of C++ core that is used for retrieving the data, parsing the XML, saving the results in a sqlite database (that stores the xml retrieved and associates to them the downloaded podcasts), and controlling the media playing the with mplayer.

All this is quite well done, however around this there’s a C/Elmentary interface that looks quite cool and that is quite well designed, but that is badly written and that doesn’t uses the E-libraries to perform some basic tasks (like downloading the media). This causes that the interface is often blocked while the core is performing some task (like reading from the database or parsing the xml files). The author said that he wrote the reader in few days so we understand why there are so much workarounds around in the code. Of course these workarounds need to be fixed (with the bugs that they bring).

POTENTIAL
At the current state it’s not usable but it can be improved to do the task it’s meant to do. The potential of this application is good since the it already allows to listen multiple podcast sources (that can be added pasting the feed url), saving the selected media in the phone and allowing to listen it lately. All this is doable using a very well finger usable interface. There’s also a nice interface for mplayer, also if it has some speed issues when NeoReader is used in a real device.

Some features we’d like to see in this software (after getting a stable version that should use the e libraries facilities for getting the base task accomplished, of course :P), are a kind of playlist that should show all the downloaded media (per podcast and general), the ability to use an plain file to save the podcast addresses (so it will be easy to share list of podcasts or simply to import them without using the GUI). Also a package for easier installation, completed support for podcast management (add/remove feed) and some more information added (downloading, play time etc) and local music/audio book file support added.

CONCLUSION
The parts that work, seem to work well. Even if it has many bugs, the interface must be improved, and the code cleaned up, it represents ~the best starting point for having a nice podcast player for Openmoko. Good backed, nice elementary GUI but badly integrated with the core, it’s developed for being just a podcast reader and it seems a good first step.

Developers: Thomas Roth <nezzaATymail-com> + Mikael Voss
Files & installation instructions
Neoreader website

And the winner is…

.. the community! We just weren’t able to decide if Neoreader or Gorshplayer was better: at the current state they both have some very strong elements and on the other hand some huge weaknesses so it wouldn’t be fair to decide that one of these is the winner. So we want to congratulate both Neoreader and Gorshplayer developers for the job they did – we decided to split the prize between these two projects. The prize, currently at 344e + a leather Openmoko case, can be seen at Cofundos. Everyone who bidded at Cofundos will be soon sent a message telling them to contact both Neoreader & Gorshplayer authors to get the payment instructions. Please pay 50% of your bid to Neoreader devels and 50% to Gorshplayer devel. Also, if anyone else is interested in rewarding the developers for their work feel free to contact them and ask for the payment details.

We also want to encourage you to participate in these projects to complete the missing features and polish them so that we’ll soon be able to listen to podcasts and audio books with no hassle.

We want to thank everyone who contributed: developers, people who give their money to award the developers, the jury members and everyone who sent us comments and suggestions. Please let us know if you think a competition like this is a good idea to run again, what would you like to see as topics and if you have any other ideas and thoughts about this, please share it with us!

Related posts:

Tags: , , , , , , ,

  1. David Samblas’s avatar

    David Samblas on April 5, 2009 at 11:56 pm

    :) well I see I have to ship two leather cases , It would be unfair to have a half a case each winner.XD I try to give tree apps a try and make some report :)
    Thanks all organizers, bidders and participants to go an step forward of had cool apps in the Neo.

  2. nezza-_-’s avatar

    nezza-_- on April 6, 2009 at 2:03 am

    Mh, I’m wondering why you don’t have the timeline in NeoReader (http://0×2a-blog.org/files/06042009/3.png).. I will take a look at the whole thing as soon as I find some time to create the project page etc.

    Thanks!

    nezza-_-

  3. Risto H. Kurppa’s avatar

    Risto H. Kurppa on April 6, 2009 at 11:31 am

    @nezza: Congrats again :) I added a link to your site in this post, if you start a trac/project site, please let us know.

    We were running it on 2008.12, that’s maybe the reason why the I was broken but we weren’t able to make it run on SHR. Anyway, we’re waiting to hear more from you :)

  4. Wilder’s avatar

    Wilder on April 6, 2009 at 3:12 pm

    Congratulations!

  5. Treviño’s avatar

    Treviño on April 10, 2009 at 2:30 am

    Hello, I’m Marco Trevisan, one of the people behind the polls…
    So, for clarity I’m posting here (a bit late, sorry), my personal evaluations about the three candidate projects:

    Mokotunes
    ———-
    This can be considered just a little more than a nice mockup just now
    since most part of the core functionalities are not implemented yet. By
    the way, looking at its code (that mostly presents some skeleton
    functions), I can say that is a very well written/structured C++/EFL
    project that uses edje for designing the interface while Gstreamer to
    play the media (actually impossible due to the missing interface for
    retrieving the data, but the code for playing seems to be all there!).
    So, also if what I’ve considered is still something of embryonal, the
    core that has already written seems so good, and it could be extended to
    get something of functional one day.
    >From the GUI point of view, imho, it’s hard to do a consideration, since
    actually it only shows a kind of “demo” playlist with some buttons for
    controlling the media reproduction. However I don’t know how it’s
    planned the management of the podcast feeds and of the downloads.
    Finally, from a first test in my Freerunner, the interface seems a
    little slow. Also if it includes only few elements in its list, the
    scrolling is not so smooth (maybe due to the pixmaps used in the
    theme!?) so I don’t expect it to be better in a real scenario.

    My vote: 3/10.
    In few words: Good start, nice code, but too immature into an unlikely
    interface.

    Gorshplayer
    ———–
    It was the only project sent that was working “by default”, and
    basically the author added a new podcast media importer feature to the
    existent Neoqplayer/Gorshplayer code.
    So, with it is possible to add a podcast url, browse its content,
    download it and reproducing it from the playlist (as any other media
    that is loaded there). This seems to work quite well also if I was able
    to get only ogg files working, however the interface imho isn’t so good
    for two reasons: first of all it is not so finger usable (yes, the
    buttons are big enough, but there’s no finger scrolling, and
    double-clicking is hard! Not to mention that the window is too big to be
    used with a shelf, so it’s made for working in fullscreen), then to add
    a podcast an user should go into preferences, paste an URL, go in the
    podcasts list, load a podcast, double-click an item to download, go back
    to the main window where he can select the media to reproduce. All this
    is quite annoying.
    The player is written in C++/Qt and that is a very good choice in
    general, but unfortunately not for the openmoko applications yet. In
    fact this toolkit doesn’t support by default some finger-friendly
    features that could improve a lot the usability, and from the user point
    of view, it is not so easy to be installed in the most part of the
    distros available natively for the Openmoko devices (also if it works,
    I’ve ran it also in Om2008). Of course this is not a developer fault,
    and I guess that this player is a very good choice for distros like
    debian (when I mean with it something of “non-telephonic”), but I think
    that the toolkit choice is what mostly limited my judgment (that is
    mostly focused for getting something of working in a touchscreen daily
    device).
    I hope, however, that it will improve making the podcast reproduction a
    little bit more friendly.

    My vote: 5.5/10
    In few words: Good player, well written, works, but not focused for the
    podcast playing, not so finger usable, not yet ready for any
    “telephonic” distro (SHR/OM).

    NeoReader
    ———
    When I received the code it seemed neither compilable for an openmoko
    phone (no problems in my PC, instead), however playing a little with the
    Toolchain I got an arm binary. Unfortunately everywhere I’d run this
    software, it simply crashed when I tried to fetch the podcast media.
    So, if I’d judge its basic functionality, I should say that it simply
    doesn’t work. However I liked the idea behind the interface, so I fixed
    a little the code to get it working…
    Looking at it a little more deeply, I found that it has a kind of C++
    core that is used for retrieving the data, parsing the XML, saving the
    results in a sqlite database (that stores the xml retrieved and
    associates to them the downloaded podcasts), and controlling the media
    playing the with mplayer.
    All this is quite well done, however around this there’s a C/Elmentary
    interface that looks quite cool and that is quite well designed, but
    that is imho badly written and that doesn’t uses the E-libraries to
    perform some basic tasks (like downloading the media). This causes that
    the interface is often blocked while the core is performing some task
    (like reading from the database or parsing the xml files). The author
    said that he wrote the reader in few days so I can understand why there
    are so much workarounds around in the code, but I think that they must
    be absolutely fixed (with the bugs that they bring).
    By the way the potential of this application is good since the it
    already allows to listen multiple podcast sources (that can be added
    pasting the feed url), saving the selected media in the phone and
    allowing to listen it lately. All this is doable using a very well
    finger usable interface (thanks to the tools that Elementary gives).
    There are is also a nice interface for mplayer, also if it has some
    speed issues when NeoReader is used in a real device.
    So finally, I’ve decided to give my vote to this application because
    also if it has many bugs, the interface must be improved, and the code
    cleaned up, it represents imho the best starting point for having a nice
    podcast player for Openmoko.
    Some features I’d like to see in this software (after getting a stable
    version that should use the e libraries facilities for getting the base
    task accomplished, of course :P), are a kind of playlist that should
    show all the downloaded media (per podcast and general), the ability to
    use an plain file to save the podcast addresses (so it will be easy to
    share list of podcasts or simply to import them without using the GUI).

    My vote: 7/10
    In few words: Good backed, nice elementary GUI but badly integrated with
    the core, it’s developed for being just a podcast reader and it seems a
    good first step.

    Bye.

  6. Yogiz’s avatar

    Yogiz on April 11, 2009 at 2:37 pm

    The competition was nice but not quite as well thought out as it could have. If I had donated in confundos for it, I would be rather dissapointed right now, as none of the projects are good enough to include to the Freerunner. I’d suggest giving a longer deadline, two or three months, and hold only one competition at any given time. That way the devs could actually churn out polished code instead of how it went now. I’d make the competition last three months and allow anyone to join in at any time, not just at the beginning. Also there should be a threshold for quality or something. If at the end of the deadline none of the projects are good enough, then just extend the deadline or forfeit the prize. Just my $0.02, worth thinking about though.