19 May 2013

feedPlanet Maemo

SeriesFinale for BlackBerry

I would like to share with you this port of SeriesFinale for Blackberry.

Unlike the other versions, I was not involved in the development of this one. It was developed by Micke Prag, who also started the Meego/N9 port back in the day.
I developed the first version of SeriesFinale in 2009 for the defunct Maemo system and released also a version for the N9/Meego in 2011 (there was also a version for GNOME but I never finished it…). It is very good to see that it continues its life even if I am not involved this time.

I don't own a BlackBerry so I am not able to try it but judging from this video, it definitely looks good so if you're a BB user, check it out!

Judging from the success that a clone for Android and a similar online service have, it seems like I could have started a whole business out of it… :)

0 Add to favourites0 Bury

19 May 2013 9:51am GMT

16 May 2013

feedPlanet Maemo

Behind the Scenes: Headset Camera app for the N9

The logical step after the "Volume+ as Camera Button" app (Nokia Store link) for the N9 is another app that allows you to take photos while not touching your N9 at all. While time-triggered photos are fun, remote-triggered photos are.. erm.. "funner"? So what kind of remote "buttons" can we easily get on the N9? The remote control button on the headset is both "remote" and a "button". Also, as seen in Panucci and gPodder versions since the N900, Bluetooth headset buttons can also be queried by applications. So what do we get by combining remote control and photo taking? The Headset Camera app (Nokia Store link) for the N9! Or - for the visual reader - this:



If you want to integrate such features into your own app, the code for querying the headset buttons is readily available in the gPodder source tree (src/gpodder/qmlui/helper.py):

import dbus

class MediaButtonsHandler(QtCore.QObject):
def __init__(self):
QtCore.QObject.__init__(self)
headset_path = '/org/freedesktop/Hal/devices/computer_logicaldev_input_0'
headset_path2 = '/org/freedesktop/Hal/devices/computer_logicaldev_input'

system_bus = dbus.SystemBus()
system_bus.add_signal_receiver(self.handle_button, 'Condition',
'org.freedesktop.Hal.Device', None, headset_path)
system_bus.add_signal_receiver(self.handle_button, 'Condition',
'org.freedesktop.Hal.Device', None, headset_path2)

def handle_button(self, signal, button):
if signal == 'ButtonPressed':
if button in ('play-cd', 'phone'):
self.playPressed.emit()
elif button == 'pause-cd':
self.pausePressed.emit()
elif button == 'previous-song':
self.previousPressed.emit()
elif button == 'next-song':
self.nextPressed.emit()

playPressed = QtCore.Signal()
pausePressed = QtCore.Signal()
previousPressed = QtCore.Signal()
nextPressed = QtCore.Signal()

MediaButtonsHandler is already a QObject subclass, so you can easily expose an instance of this class to your QDeclarativeView rootContext() and connect to the signals in QML (such a "headset button handler" might actually be a good candidate for inclusion into nemo-qml-plugins in Sailfish OS and Nemo Mobile?). As it's really just using the Python D-Bus bindings to get property changes from Hal devices, the code above should be easy (read: trivial) to port from Python to Qt/C++. Be aware that you need to connect to both .../computer_logicaldev_input_0 and .../computer_logicaldev_input, which can both exist if you have a cable headset and a Bluetooth headset connected at the same time.

You can get the Headset Camera App for the N9 in Nokia Store now, there is also a video on YouTube showing the app. Or start integrating headset button features into your own app or scripts by adapting the code above. One use case that comes to mind is using the previous/next buttons on a Bluetooth headset to control a photo slideshow on the N9 connected to TV-Out. Enjoy :)1 Add to favourites0 Bury

16 May 2013 11:00am GMT

14 May 2013

feedPlanet Maemo

HTML5 Web Apps on Mobile Devices

Get out your Buzzword Bingo cards, we're talking HTML5. And Canvas2D. And WebGL. See? Check them off and then continue reading. So, while writing "native" apps using JavaScript is definitely possible and works great with QML, some games are just simple enough (or want to have a broad enough audience) to warrant writing everything in HTML5.

This might also be a good time to check off XmlHttpRequest on your BB card, even if none of the following games use it - you might want to use it in your applications or game for things such as server-side stored high scores.

As far as Maemo and MeeGo is concerned, you might want to try out some of these games (especially the WebGL variant of One Whale Trip) in Fennec (aka Mobile Firefox - get it for: N900, N950/N9, Nemo Mobile).

Color Lines: This one simply uses Canvas2D, and works nicely on all mobile browsers that I tested - Maemo, MeeGo, Android, WP7.5, BB Playbook, iOS. Comes in at about 650 lines of rather well-documented JavaScript, and could easily be ported to use QML as a renderer if need be (it would be good to have a QML Plug-In that provides a JavaScript context + (a subset of) the Canvas2D API - without using WebKit (cross that off, too), that is). Also, the N900's stock browser has performance problems rendering this, while on the same device in Fennec it's quite playable.

Circle1D: This is a straight Python-to-JavaScript port of a lame 2D "Physics" Engine. It's kept very (read: very, very) simple, and collision detection could be done in a nicer way, but the inefficiency of it provides a nice benchmark for comparing JavaScript engine performance (I'm sure you can find "engine performance" on your bingo card as well) on mobile devices. The N900's default browser can't handle it at all, but Fennec can at least render/simulate it, albeit slowly.

One Whale Trip: This game actually started out as a Python game for PyWeek last September, which was also ported to the N950/N9, but as a test for trying out WebGL, I decided to port it from Python/PyGame to JavaScript/Canvas2D and then to WebGL (the Python version also contains two renderers - a "blitting" one using PyGame surfaces, and an OpenGL one using OpenGL [ES 2 on mobile]). The Canvas2D version works again in all modern mobile browsers (same as above), the WebGL only works on browsers supporting WebGL, for example Fennec/Firefox on both the N900 (even though very slowly) and not in any of the stock browsers (even not the one on the N9). As WebGL is "roughly" the same as OpenGL ES 2.x, one could imagine sharing at least shader programs for a possible C++-or-JavaScript cross-platform application.

So yeah, for smaller applications and/or games, HTML5 is definitely an option. In Firefox OS, your HTML5 web app will - also with WebGL - work and integrate nicely as "native" app. If you also want to create "native" applications (maybe after finishing the HTML5 version), consider encapsulating your JavaScript code so that you can re-use it in QML code, or (in case of WebGL apps), at least design the rendering part of your application in such a way that the code/architecture and shader programs can be shared with a C++ port of your existing HTML5 app.

Another option that's worth considering: Writing a compatiblity application layer that can load (specially-crafted) WebGL subset applications and display them on a fullscreen SDL-(or Qt)-provided window. Applications written in this WebGL subset could then be deployed on the web as HTML5 application or "natively" running on top of a JavaScript engine only. I'd call that "webglenv", and no, I haven't written it yet.1 Add to favourites0 Bury

14 May 2013 8:28pm GMT

Tizen Developer Conference coming up...

The Tizen Developer Conference is coming up from the 22nd of May until the 24th of may 2013 - It is in Downtown San Francisco (https://www.tizen.org/)
I will be there the whole 3 days but I might be hard to grab as I will be running around. If you want to touch base - just contact me through linked in, email or twitter (https://twitter.com/yapellet).

If you are going there, go and check out the following talks from my lab (SRA's Advanced Software Platform). One is "Accelerated HTML5 Rendering for the Tizen Platform" by Henry Song. The other is "WebKit for Tizen" by Laszlo Gombos. Both of those talks are on the WebKit track. Though they are litteraly the top of the iceberg when it comes to our activity, it gives you an idea of what some our interests are.

There is also a presentation around a service prototyping for social appointment entitled Rendez-vous under the Tizen Collaboration Projects. This is presented by Stanford students. It is a small project that we kick-started and sponsored last February as part of the CS210 Stanford Class.

On side note: Art Dahm is giving a talk about building Tizen apps using Enyo & Phonegap. Art - now working for LG - used to be part of my team working when I was working on webOS at HP. I will be sure to check this one out to see if I can meet some of the old team :)

See you there.

1 Add to favourites0 Bury

14 May 2013 7:50am GMT

13 May 2013

feedPlanet Maemo

Qt5 Battery Component

After the QUItIndicator trilogy which introduced idea, design and performance of a specific Qt5 QML component there's room for more, right?! Something like this:


This time we have a dynamic QML component for showing the remaining power of your mobile device battery. As a recap, with "Dynamic QML component" I mean someting which utilizes not only basic QML animation properties (position, opacity, scale etc.) but also new Qt5 features (shaders, particles, scenegraph powa!) to appear "more dynamic". Maybe it's just me, but I would love to see UIs really utilizing modern GPUs... and accelerating this progress is one of the reasons why I code these examples and blog about them. Another reason being to rule-the-world, obviously ;-P

Instead of explaining design & features of QUItBattery component I'll let this video to do that:





If you want to use this liquid battery component in your UI: Download the sources from here, copy QUItBatteryComponent directory, import it in your QML and off you go. Happy hacking!

1 Add to favourites0 Bury

13 May 2013 8:34am GMT

MWKN Weekly News for Monday, 13 May 2013

Front Page

New Maemo Community Council and Hildon Foundation Council elected

Last week, the new Maemo Community Council and the inaugural Hildon Foundation Council were elected. On behalf ofthe MWKN staff, your editor would like to congratulate the new council members: "Q2 2013 Maemo Community Council: Rüdiger Schiller (chemist), Joerg Reisenweber (DocScrutinizer/joerg_rw), Christian Ratzenhofer (merlin1991), Michael Demetriou (qwazix), and Akash Sadh (Kash)"

"Inaugural Hildon Foundation Council: Rüdiger Schiller (chemist), Joerg Reisenweber (DocScrutinizer/joerg_rw), Christian Ratzenhofer (merlin1991), Michael Demetriou (qwazix), and Paul Healy (sixwheeledbeast)"

Sadly the plan to have both votes result in identical councils to allow the merging of the Maemo Community Council and the Hildon Foundation Council into a single body did not work out, resulting in a situation with separate Maemo Community and Hildon Foundation councils that cannot be easily merged. In practice, it seems likely they will end up operating mostly like a single 6-person body.

Read more (thread.gmane.org)

Logs from the Maemo Community Council handover meeting available

The Maemo Community Council handover meeting was held last week. The minutes have not yet been posted, but the logs are available. The meeting mostly dealt with formalities of the handover, but there was some interesting discussion about the banking details of the Hildon Foundation. Rather than coloring the discussion with his own interpretation, your editor suggests reading from about 22:30 onward in the logs. It deals primarily with Hildon Foundation funds, donations, bank account access for new board members and the resigned treasurer, and future board meeting scheduling (or lack thereof).

Read more (mg.pov.lt)

In this edition (Download)...

  1. Front Page
    • New Maemo Community Council and Hildon Foundation Council elected
    • Logs from the Maemo Community Council handover meeting available
  2. Community
    • Hildon Foundation Board meeting minutes from April 19, 2013 posted

1 Add to favourites0 Bury

13 May 2013 12:00am GMT

12 May 2013

feedPlanet Maemo

Large-scale sparse multiclass classification

I'm thrilled to announce that my paper "Block Coordinate Descent Algorithms for Large-scale Sparse Multiclass Classification" (published in the Machine Learning journal) is now online: PDF, BibTeX [*].

Abstract

Over the past decade, l1 regularization has emerged as a powerful way to learn classifiers with implicit feature selection. More recently, mixed-norm (e.g., l1/l2) regularization has been utilized as a way to select entire groups of features. In this paper, we propose a novel direct multiclass formulation specifically designed for large-scale and high-dimensional problems such as document classification. Based on a multiclass extension of the squared hinge loss, our formulation employs l1/l2 regularization so as to force weights corresponding to the same features to be zero across all classes, resulting in compact and fast-to-evaluate multiclass models. For optimization, we employ two globally-convergent variants of block coordinate descent, one with line search (Tseng and Yun, 2009) and the other without (Richtárik and Takáč, 2012). We present the two variants in a unified manner and develop the core components needed to efficiently solve our formulation. The end result is a couple of block coordinate descent algorithms specifically tailored to our multiclass formulation. Experimentally, we show that block coordinate descent performs favorably to other solvers such as FOBOS, FISTA and SpaRSA. Furthermore, we show that our formulation obtains very compact multiclass models and outperforms l1/l2- regularized multiclass logistic regression in terms of training speed, while achieving comparable test accuracy.

Code

The code of the proposed multiclass method is available in my Python/Cython machine learning library, lightning. Below is an example of how to use it on the News20 dataset.

from sklearn.datasets import fetch_20newsgroups_vectorized
from lightning.primal_cd import CDClassifier
 
bunch = fetch_20newsgroups_vectorized(subset="all")
X = bunch.data
y = bunch.target
 
clf = CDClassifier(penalty="l1/l2",
                   loss="squared_hinge",
                   multiclass=True,
                   max_iter=20,
                   alpha=1e-4,
                   C=1.0 / X.shape[0],
                   tol=1e-3)
clf.fit(X, y)
# accuracy
print clf.score(X, y) 
# percentage of selected features
print clf.n_nonzero(percentage=True)

To use the variant without line search (as presented in the paper), add the max_steps=0 option to CDClassifier.

Data

I also released the Amazon7 dataset used in the paper. It contains 1,362,109 reviews of Amazon products. Each review may belong to one of 7 categories (apparel, book, dvd, electronics, kitchen & housewares, music, video) and is represented as a 262,144-dimensional vector. It is, to my knowledge, one of the largest publically available multiclass classification dataset.

[*] The final publication is available here.

1 Add to favourites0 Bury

12 May 2013 12:52pm GMT

Petals for Harmattan - A pure Qt4/Qt5 JS/QML puzzle game

Next up in my list of things I did in the last weeks/months and never blogged about is Petals (Nokia Store link), a "beautiful, brain-teasing puzzle game for 1-4 players" if the game's website is to be believed (I would like to think it is...). As always, there's some technical details about the porting and creation of this game. While another recent game (Tetrepetete) has been done on a low level (C++ using no frameworks, and interfacing with multiple front-ends directly, including an OpenGL ES frontend, a console-based ncurses frontend(!) as well as a server-sent events/XHR/Canvas2D-based HTML5 frontend(!!)), this one is approaching things from a very high level: JavaScript.

Petals: A puzzle game written in pure JavaScript and QML

The gameplay logic of the game is implemented in pure JavaScript (without any QML dependencies), so it could easily be ported to, say, HTML5, but for integration reasons, QML seemed like the better choice for a release on the N9/Harmattan. Also, writing things in JavaScript wouldn't preclude a console-based frontend using nodejs and node-ncurses from happening should the need arise (making the flowers look good in ASCII art would be the challenge there - or cheating by using libcaca). Ok, ok - stop cursing, I'll stop talking about curses (cue laugh track).

Writing pure QML applications has the advantage of easing porting to Qt 5. While QtQuick 1.1 still exists on Qt 5 (and is the only QML option at the moment if you are also targetting iOS), QtQuick 2.0 is usually the better choice for performance reasons.

In my case, the changes necessary to port from QtQuick 1.1 to QtQuick 2.0 were:

And that's basically it. Of course, as this is a full-screen game with custom UI, no platform-specific components (such as Harmattan Components or Sailfish Silica) are used, so porting is a bit easier there (no need to "wait" for specific components to be compatible with QtQuick 2.0, which might realistically not happen at all for Harmattan Components). More screenshots of Petals and download links for multiple platforms can be found on the Petals Website.1 Add to favourites0 Bury

12 May 2013 11:30am GMT

11 May 2013

feedPlanet Maemo

Board Meeting Minutes of April 19, 2013

Board Members Attending:

Personnel and Organization

1 Add to favourites0 Bury

11 May 2013 9:10pm GMT

08 May 2013

feedPlanet Maemo

Wayland utilizing Android GPU drivers on glibc based systems, Part 2


In this blog series, I am presenting a solution that I've developed that enables the use of Wayland on top of Android hardware adaptations, specifically the GPU drivers, but without actually requiring the OS to be Bionic based.

This is part 2 and will cover the actual server side (and a little bit about generic EGL implementation) of the solution. The first part can be read here. The third and last blog post will revolve around the client side solution and how you can use it today, as well as future work. There are a -lot- of links in this blog, please take a look at them to fully understand what is being explained.

This work was and is done as part of my job as Chief Research Engineer in Jolla, which develop Sailfish OS, a mobile-optimized operating system that has the flexibility, ubiquity and stability of the Linux core with a cutting edge user experience built with the renowned Qt platform.

The views and opinions expressed in this blog series are my own and not that of my employer.

The aim is to have documented the proof of concept code and published it under a "LGPLv2.1 only" license, for the benefit of many different communities and projects (Sailfish, OpenWebOS, Qt Project, KDE, GNOME, Hawaii, Nemo Mobile, Mer Core based projects, EFL, etc).

This work is done with the hope that it will attract more contribution and collaboration to bring this solution and Wayland in general into wider use across the open source ecosystem and use a large selection of reference device designs for their OS'es.

Rendering with OpenGL ES 2.0 to a screen with Android APIs

In Android, when SurfaceFlinger wants to render to the screen, it utilizes a class named FramebufferNativeWindow which it passes to eglCreateWindowSurface. As I mentioned in my previous post, on Android, when you use eglCreateWindowSurface you utilize a type/'class' named ANativeWindow. FramebufferNativeWindow implements this type. This then means it gets buffers utilizing FramebufferNativeWindow, renders to them within the OpenGL ES 2.0 implementation and queues them to be shown on the screen utilizing the same FramebufferNativeWindow.

But what happens under the hood? I'll try to explain with libhybris' "fbdev" windowing system as an example.

We're back to ANativeWindow - what libhybris' "fbdev" windowing system does is practically to do an implementation of ANativeWindow.

When a OpenGL ES 2.0 implementation wants to have a buffer to render into, it will call the dequeueBuffer method of an ANativeWindow. This usually happens upon surface creation or when you have done eglSwapBuffers and would like a new fresh buffer to render into.

You may have heard of fancy things like 'vsync' and you know that you have to follow signaling of vsync to avoid things like tearing. On the occasion that you do not have any buffers available (as some might be waiting to be posted to the framebuffer), you will need to block and wait for a non-busy buffer to be available within a dequeueBuffer implementation - don't just return NULL. Use pthread conditions and be CPU-friendly. This also makes sure you will block in eglSwapBuffers()

A quick note for implementors of ANativeWindow: Many OpenGL ES drivers are very temperamental. When it relays the information to you that it wants to set your buffer count to 4 buffers, it means that it wants 4 buffers and only to see those 4 buffers in the lifetime until usage or format changes. Mess up and it will happily crash on you - these drivers do not come with debug symbols.

When you want to allocate graphical buffers you naturally need gralloc to do so - gralloc is a module that is accessible through Android's libhardware API - in practice, gralloc is a shared object that libhardware dlopen()s, see /system/lib/hw/ for examples of these (gps, lights, sensors, etc).

When loading gralloc you will naturally get the interface of the gralloc module itself, but when you initialize gralloc, you get an allocation device interface where you can allocate and free buffers with, by specifying parameters such as width, height, usage, format. Usage is important since we'd like to allocate buffers for use with the framebuffer - so when we allocate a buffer, we allocate with usage 'usage | GRALLOC_USAGE_HW_FB'.

The return value of the alloc() call is a integer value indicating if it was a success, a native handle in the provided memory location (read my previous blog post for an explanation on what this is) and stride of the buffer.

We then wrap the handle and related information in a ANativeWindowBuffer structure and pass it back to the caller. Please note two things in this structure. incRef and decRef - they are very important. You will need to implement reference counting and you will need to increase/decrease your reference counting matching your own references to it. When reference count reaches 0, the buffer should destruct.

Eventually we will then get the buffer back from the caller in queueBuffer -- but how do we now send it to the framebuffer to be displayed?

In the initialization of our framebuffer window, we should have also opened the framebuffer with the libhardware API. It is in the same hw_module_t as gralloc. The framebuffer interface includes handy information such as the width, height, format, dpi and a few methods to actually utilize the framebuffer. The most important one for us is post(). This allows us to flip an actual buffer to the screen - utilizing the buffer handle, provided it has the same width, height/format as framebuffer and is allocated with appropiate usage (framebuffer usage). This call will on occasion block.

We have to be careful not to deliver the current front buffer to the caller in dequeueBuffer until we have replaced it with another at the front of the screen or we may see flickering.

A note to users of libhybris: there may be some Android adaptations that implement a custom framebuffer interface requiring extra implementation to achieve sane posting of frames that blocks. Check your FramebufferNativeWindow.cpp for this. This does not seem to be pervasive but I've encountered it on HP Touchpad with CyanogenMod/ICS.

Server-side Wayland enablement

The wayland protocol has two sides, server - and client. But unlike X, there is no "Wayland server". The implementation of the protocol communication for each side is implemented in respectively libwayland-server and libwayland-client. When implementing a compositor, you then utilize libwayland-server API to create server sockets, do communication, etc.

But how does the EGL stack get to be connected to a Wayland server instance when the associated EGLDisplay the stack is connected to, probably isn't a Wayland display? (note: may be in nested compositors - ie, a Wayland compositor running as a client to another Wayland compositor) That's where the next topic comes in:

EGL extensions - EGL_WL_bind_wayland_display

In order to connect your EGL stack to a Wayland display, you need to bind to one - you do this with eglBindWaylandDisplay(EGLDisplay, struct wl_display *) from the EGL_WL_bind_wayland_display. In libhybris, we provide this extension when it has been configured with --enable-wayland and available in most windowing systems (we provide an environment variable EGL_PLATFORM to select between 'windowing systems). Since the extension is not just part of the Wayland windowing system, it is possible to do nested Wayland compositors.

But what happens in libhybris when you bind to a Wayland display? We call the server_wlegl_create method in server_wlegl.cpp. What this does is to add a global object to the Wayland protocol - with a certain interface, - but where is this interface defined? As it has to be shared between both client and server; it is specified in a xml format file that is then converted by a tool called 'wayland-scanner' into .c files that are then linked into your client or server part. We then implement the actual interfaces for server side in our code.

Creation of buffers

When a client requests to create a buffer, it first creates an Android native handle object on server side and shares the client's native handle through the Wayland protocol (utilizing the support for fd passing) and then actually asks to create the buffer (note: we actually created the buffer on client side, now we're just sharing it with the compositor and letting it know the details).

When that happens on libhybris side, is when a handle is created, we construct an Android native_handle_t on server side - with the correct fd and integer information. We then map this with registerBuffer into the compositor's address space so the buffer is available to EGL and related stacks.

Once we have the handle in place, we can now create an Android native buffer - like we made ANativeBuffer on client side in the framebuffer/generic window scenario, we make one representing the remote buffer with the reconstructed handle. Finally we construct a Wayland object referencing this Android buffer and increase the reference counter of the Android buffer - and pass the buffer back to the Wayland client.

When we want to destroy the buffer again (well, when the reference count reaches 0), we unregister the buffer and close the native handle.

Utilizing a Wayland-Android buffer as part of your scenegraph

When a compositor would like to utilize a Wayland buffer in general, it uses eglCreateImageKHR with the EGL_WAYLAND_BUFFER_WL target and passing the (server-side) wl_buffer. This means that the compositor does not have to worry about the factual implementation of the wl_buffer behind the scene.

In our case, our wl_buffer is the one we indicated above - so we know it actually encapsulates a ANativeWindowBuffer with a handle/width/height etc. The knowledged reader might realize that eglCreateImageKHR in the Android EGL implementation does not support EGL_WAYLAND_BUFFER_WL. It does however support EGL_NATIVE_BUFFER_ANDROID

The way that this is handled is that we wrap eglCreateImageKHR and when we see EGL_WAYLAND_BUFFER_WL, we call the real eglCreateImageKHR with EGL_NATIVE_BUFFER_ANDROID - with the ANativeWindowBuffer. And we get the Wayland client's buffer as part of our OpenGL scenegraph.

This way we can also easily implement method such as eglQueryWaylandBufferWL as we know the attributes of the Android buffer.

An implementor's note: the destructor of a buffer is first called with wl_buffer_destroy coming from client side. You'll have to remember reference counting and not just delete the buffer

Conclusion

Thanks for reading this (rather technical) second blog post, the third one should follow quite soon. The code is already published and continually developed in http://github.com/libhybris/libhybris but it's not easy to approach or use for general users or developers right now.

The final post will describe how you can use this solution together with QtCompositor on top of Mer Core as well as describe how the Wayland client side works to make all this tie together. You can already now study, comment or flame the client side implementation. But for the explanation and for a description of what is missing, you'll have to wait for next one :)

Feel free to join us in #libhybris on irc.freenode.net to discuss and contribute to this work.

1 Add to favourites0 Bury

08 May 2013 8:22pm GMT

Upcoming: Billboard 1.0.9 for Nokia N9

Turns out I haven't posted here for two months, so here we go again: Billboard, your favorite low-power mode standby screen will soon receive a new update - version 1.0.9 has been uploaded to Nokia Store QA two days ago, and should hopefully pass QA and be available as an update in the next few days. This release brings a few major under-the-hood improvements and small bugfixes:

With the new formatter, you can now output {} expressions in your scripts so that they get replaced, and similarly pass {} expressions as parameters to your scripts (for example to modify them in some way before displaying). This should allow for even more customization, some examples of what users have been doing on their N9 standby screen can be seen in the Billboard Standby Screen support thread on talk.maemo.org.

If you are looking for additional ways to tweak and enhance your Billboard-on-N9 experience, have a look at billboard-scripts, a growing collection of Shell and Python scripts that provide even more ways of customizing your standby screen.

If you haven't purchased Billboard from Nokia Store yet, you can get the current version now for your N9, and get the upgrade to 1.0.9 as soon as it's available. If you are already a happy user, watch your application updates in the next few days, and get the new version.1 Add to favourites0 Bury

08 May 2013 7:20pm GMT

Save Ferris: Show some love for libferris...

Libferris has been gaining some KDE love in recent times. There is now a KIO slave to allow you to see libferris from KDE, also the ability to get at libferris from plasma.

I've been meaning to update the mounting of some Web services like vimeo for quite some time. I'd also like to expand to allow mounting google+ as a filesystem and add other new Web services.

In order to manage time so that this can happen quicker, I thought I'd try the waters with a pledgie. I've left this open ended rather than sticking an exact "bounty" on things. I had the idea of trying a pledgie with my recent investigation into the libferris indexing plugins on a small form factor ARM machine. I'd like to be able to spend more time on libferris, and also pay the rent while doing that, so I thought I'd throw the idea out into the public.

If you've enjoyed the old tricks of mounting XML, Berkeley DB, SQLite, PostgreSQL and other relational databases, flickr, google docs, identica, and others and want to see more then please support the pledgie to speed up continued development. Enjoy libferris!

Click here to lend your support to: Save Ferris: Show some love for libferris and help kick it

0 Add to favourites0 Bury

08 May 2013 1:57am GMT

06 May 2013

feedPlanet Maemo

MWKN Weekly News for Monday, 6 May 2013

Front Page

Nominations over for Maemo Community Council and Hildon Foundation Council

Last week, Michael Demetriou announced the closure of the nominations for Maemo Community Council and Hildon Foundation Council: "The nomination period for candidates for the upcoming Maemo Community Council and Hildon Foundation Council has ended on the 23rd of the current month of April. The voting begins on Tuesday the 30th of April. We are happy to see more than enough candidates to hold an election this time. The candidates are as follows: Rüdiger Schiller (chemist), Joerg Reisenweber (joerg_rw/DocScrutinizer), Edoardo Spadolini (kerio), Christian Ratzenhofer (merlin1991), Aakash Sadh (Kash), Michael Demetriou (qwazix), and sixwheeledbeast (sixwheeledbeast)."

Read more (talk.maemo.org)

Voting for Maemo Community Council and Hildon Foundation Council begins on 2013-04-30 at 23:59 UTC

The election for Maemo Community Council and the Hildon Foundation Council will be opening this week on 2013-04-30 at 23:59 UTC. The election should run through Tuesday 2013-05-07 at 23:59 UTC.

The election will be for both the Maemo Community Council and a Hildon Foundation Council. Unfortunately, this situation arose by happenings that seem primarily rooted in political motivations. These motivations prevented the current Maemo Community Council from taking on the mantle and responsibilities of the Hildon Foundation Council to provide for a smooth transition.

The compromise reached has left the electorate voting on one set of candidates for two bodies, with the idea being that voters can voice their opinion about whether the Maemo Community Council and Hildon Foundation Council should be two separate bodies or a single one by the composition of their ballots for each body (identical ballots indicating desire for a single body).

Editorially speaking, this publication is in favor of a single body. This being the only sensible interpretation of the intentions of the by-laws in providing for a Hildon Foundation Council, as a Maemo Community Council without Nokia and with a nearly-duplicate body in the Hildon Foundation Council would serve very little purpose. If you prefer to see a single council body, cast both ballots identically.

Read more (talk.maemo.org)

In this edition (Download)...

  1. Front Page
    • Nominations over for Maemo Community Council and Hildon Foundation Council
    • Voting for Maemo Community Council and Hildon Foundation Council begins on 2013-04-30 at 23:59 UTC
  2. Community
    • Voting on the Maemo Community Council election rules refendum closes

2 Add to favourites0 Bury

06 May 2013 4:00am GMT

02 May 2013

feedPlanet Maemo

QUItIndicators: Performance considerations

(This is part III, please check also parts I and II)

Even with a small component like this, there are plenty of possibilities to improve (or sink) the performance. To make sure that our indicators perform as expected, we'll test them on Nokia N9 and and on Raspberry Pi.

These both devices are relatively low-end by current standards. N9 contains 1GHz Cortex-A8 CPU which is still quite beefy, but GPU (SGX530) on the other hand is getting old and unable to handle more complicated fragment shaders. For RPi these are just the opposite: CPU is slowish 700MHz ARM11 while the GPU (VideoCore IV) is more performant than N9 SGX530. Because of these qualities (and because both support Qt5, naturally) this duo is excellent for our performance ensurement.

So here's a short video showing how our indicators perform on Nokia N9 and on RaspberryPi:




Performs pretty OK on both, right? ProgressIndicator stress test isn't smooth on RPi, which indicates that its CPU can't handle 100 indicators animated like that. So stress test does what it's supposed to, normal use cases perform well.

Even with declarative QML language, good performance doesn't just happen, you need to work towards it. By looking at the sources of these indicators, at least these tips/notes can be made:


So with all this, does it mean that these indicator components are fully optimized? Well of course not! There are still some generalization left and room for improvements. Additinally, although we have tried to offload most of the work from CPU to GPU, indicator animations like these should be run in a separate thread instead of the GUI thread. Only this would allow smooth 60fps even when processing under heavy CPU load. For details, please read this blog post by Gunnar: http://blog.qt.digia.com/blog/2012/08/20/render-thread-animations-in-qt-quick-2-0/

Summing up briefly: When implementing QML components for applications, developers and designers should co-operate closely to bend the design to be as CPU&GPU friendly as possible while still making designers happy. Designers dig perfect pixels, but they also appreciate smooth 60fps. By making wise compromises and utilizing Qt5 correctly, we can deliver both.

Sources of QUItIndicator components & examples are available from: http://quitcoding.com/?page=work#indicators

0 Add to favourites0 Bury

02 May 2013 1:34pm GMT

29 Apr 2013

feedPlanet Maemo

MWKN Weekly News for Monday, 29 Apr 2013

Front Page

Nominations over for Maemo Community Council and Hildon Foundation Council

Last week, Michael Demetriou announced the closure of the nominations for Maemo Community Council and Hildon Foundation Council: "The nomination period for candidates for the upcoming Maemo Community Council and Hildon Foundation Council has ended on the 23rd of the current month of April. The voting begins on Tuesday the 30th of April. We are happy to see more than enough candidates to hold an election this time. The candidates are as follows: Rüdiger Schiller (chemist), Joerg Reisenweber (joerg_rw/DocScrutinizer), Edoardo Spadolini (kerio), Christian Ratzenhofer (merlin1991), Aakash Sadh (Kash), Michael Demetriou (qwazix), and sixwheeledbeast (sixwheeledbeast)."

Read more (talk.maemo.org)

Voting for Maemo Community Council and Hildon Foundation Council begins on 2013-04-30 at 23:59 UTC

The election for Maemo Community Council and the Hildon Foundation Council will be opening this week on 2013-04-30 at 23:59 UTC. The election should run through Tuesday 2013-05-07 at 23:59 UTC.

The election will be for both the Maemo Community Council and a Hildon Foundation Council. Unfortunately, this situation arose by happenings that seem primarily rooted in political motivations. These motivations prevented the current Maemo Community Council from taking on the mantle and responsibilities of the Hildon Foundation Council to provide for a smooth transition.

The compromise reached has left the electorate voting on one set of candidates for two bodies, with the idea being that voters can voice their opinion about whether the Maemo Community Council and Hildon Foundation Council should be two separate bodies or a single one by the composition of their ballots for each body (identical ballots indicating desire for a single body).

Editorially speaking, this publication is in favor of a single body. This being the only sensible interpretation of the intentions of the by-laws in providing for a Hildon Foundation Council, as a Maemo Community Council without Nokia and with a nearly-duplicate body in the Hildon Foundation Council would serve very little purpose. If you prefer to see a single council body, cast both ballots identically.

Read more (talk.maemo.org)

In this edition (Download)...

  1. Front Page
    • Nominations over for Maemo Community Council and Hildon Foundation Council
    • Voting for Maemo Community Council and Hildon Foundation Council begins on 2013-04-30 at 23:59 UTC
  2. Community
    • Voting on the Maemo Community Council election rules refendum closes

1 Add to favourites0 Bury

29 Apr 2013 4:00am GMT

22 Apr 2013

feedPlanet Maemo

MWKN Weekly News for Monday, 22 Apr 2013

Front Page

This week in Maemo Community politics

Maemo Community politics always get interesting during periods of change. Nokia is in the process of handing over control of maemo.org and its infrastructure to the community, which makes this one of the largest fundamental changes in community history. Big change, lots of politics.

Last year, the Hildon Foundation was formed to act as a legal proxy to the community and provide stewardship for the infrastructure. A board of three directors was elected at that time to direct the foundation. It has, in many ways, had a rocky start. Despite success in negotiations with Nokia about the specifics of the maemo.org handover, and generous assistance from the community in the form donations (last count was totalled at several thousand dollars) and time (volunteer sysops like Falk Stern stepped up to provide support for the new infrastructure), all of the elected board members have resigned (Randall Arnold early on, and Tim Samoff and Ivan Galvez Junquera more recently), leaving a board composed entirely of appointed members. This has lead to calls from the community to hold new elections for the board.

Unfortunately, there are several issues causing contention and a number of different interpretations of how they should shake out. We're going to attempt to give you a good overview of most of the issues in question and summarize the arguments from the major positions on them. The core issue the week, though, is whether the Maemo Community Council has the authority to call for an election of the Hildon Foundation Board (which is covered further down the page).

Rob Bauer's take on the Maemo Community Council/Hildon Foundation Council distinction

One of the major issues in the recent debates is the interpretation of a clause in the by-laws which provides for a Hildon Foundation Council alongside the Hildon Foundation Board. At issue is whether the Maemo Community Council was intended to become the Hildon Foundation Council from the start, whether they were appointed as such by the initial Hildon Foundation Board, or whether there currently is no Hildon Foundation Council and one must be elected.

This is important, because the Maemo Community Council-if it's not also the Hildon Foundation Council-has no authority to call for a mid-term election of the Hildon Foundation Board. The current Maemo Community Council was attempting to call just such an election based on the all-appointed composition of the current Hildon Foundation Board and desire from members of the community to see an election to validate the board.

Posting from the Hildon Foundation account on the news page at hildonfoundation.org, RM Bauer has given us the "official" board position on the breakdown of the situation with the Maemo Community Council and the Hildon Foundation Council: "It is noted that the three current members of the Maemo Community Council have purported to appoint themselves as a three member Hildon Foundation Council and to conduct the elections of the Foundation without the Electorate and Nominations Requirements document specified in the Bylaws. This was not done through any cooperation with the Board or the community at large. It was an unofficial act, beyond the authority of the maemo community council indicated above and is of no effect."

Given that at least one member of the board does not seem to agree with this interpretation, your editor believes this post to be simply an opinion piece from Mr. Bauer and not necessarily the official stance of the board; however, a compromise was reached on this subject in the board meeting held last Friday. The summary of which we've covered later in this issue.

Read more (hildonfoundation.org)

In this edition (Download)...

  1. Front Page
    • This week in Maemo Community politics
    • Rob Bauer's take on the Maemo Community Council/Hildon Foundation Council distinction
  2. Community
    • Summary of the Hildon Foundation Board meeting
    • Summary of the Maemo Community Council meeting
    • kerio (kerio) running for Maemo Community Council
    • karmaflux (khm/karmaflux) running for Hildon Foundation Board of Directors
    • S. Howard running for Hildon Foundation Council

2 Add to favourites0 Bury

22 Apr 2013 11:17am GMT