My little app Music Shelf is a MeeGo music player that aims to be simple, easy, and good-looking. It is the proud winner of the 1st WeTab Qt App Challenge in category Entertainment with 67% of votes.

Now that the challenge is won, I'm working to target other MeeGo platforms besides the WeTab as well. Thanks to QML and Qt, this is not really a big issue.

There are bad news for N900 users, though. Maemo5 PR1.3 is not capable of running the app smoothly, so I'm not releasing it for Maemo5. The N900 MeeGo Community Edition, however, runs the app just fine.

Another target is MeeGo Harmattan for the new Nokia N950 and N9 devices, where Music Shelf does really shine!

By the way, Music Shelf is powered by the Qt incarnation of MediaBox (which is my popular Maemo4 and Maemo5 project) technology. You can expect first releases for N900CE and Harmattan soon. And on the WeTab you can already download Music Shelf version 1.0 in the WeTab Market for free.

This is an open letter to the decision-makers in the Nokia Harmattan project, prompted by Ville Vainio's suggestion.

There was an interesting issue in D-Bus, related to unicast vs broadcast signals, which led [edit: typo] to a small change in specs and which might be of some interest for D-Bus developers.

Unicast signals are not widely known and probably even less used, but they are possible.
They are useful, for instance, when you need to trigger an action from a single client, among your listeners.

Until some days ago, when a unicast signal was emitted, it was actually received by everyone listening to the signal's interface (unless a strict rule was added, unusual), waking up a number of processes which actually weren't interested in the signal.
Collateral effect, waking up cost apart: those processes might actually consider the signal as they were the actual recipient and take some action upon it. Bad.

Typical rule having this problem is "sender="org.foo,interface=org.bar".
Imagine several clients using this rule to listen to org.foo, but org.foo wanting to send a signal to :1.23 only.
Specifying destination=:1.23 for the signal object didn't really work since no dest=val was specified in the rule, allowing any destination actually matching it and all the listeners to be woken up anyway.

The problem with this situation was fixing the bad behaviour without filter out eavesdroppers, which actually wanted to receive the message even if not for them.

The solution is a sort of "eavesdrop opt-in", as Thiago proposed to add a keyword to DBusMatchRule, "eavesdrop=true|false" which defaults to false and with which the listener declares that it really wants to eavesdrop, enabling it to receive messages (including signals) not meant for it (AKA eavesdropping).
Otherwise any message (again, including signals) with a specified destination won't match a filter with no or different destination. Also a rule with a specific destination won't match broadcast messages.


In other words, by default a match rule filter will match only broadcast messages or the ones specifically for you, unless you declare your very nature of eavesdropper by adding "eavesdrop=true" to your filter rule.

This is a behavioural change and consequently means a small amend to the D-Bus spec for 1.5.x.

It also means that if you maintain some code which acts as an eavesdropper, you should fix the code adding "eavesdrop=true" to your filter.
Note that it's only for 1.5.x branch; adding the "eavesdrop" keyword to a filter sent to a 1.4.x bus will fail as the keyword is not recognized.
An example on how to deal with this change keeping compatibility toward 1.4.x (stable branch) and 1.5.x (devel branch) at the same time is shown by this bustle fix. It checks for the feature presence and prepends the keyword if supported.

#leftcontainerBox { float:left; position: fixed; top: 60%; left: 70px; } #leftcontainerBox .buttons { float:left; clear:both; margin:4px 4px 4px 4px; padding-bottom:2px; } #bottomcontainerBox { height: 30px; width:50%; padding-top:1px; } #bottomcontainerBox .buttons { float:left; height: 30px; margin:4px 4px 4px 4px; } I can deal with Apple’s just fine, as long as I don’t have to touch one, I am completely fine.  The trouble I have with the iPhone is that it feels like every man and his dog ‘must’ have one, or you’re just not cool.  What’s worse is that everything is now optimised for that [...]

Finally I could get a little time to finish SF 0.6.8 release.

The people at the helm at Nokia could see this and say, heh, do you even know our N9 strategy? Or may be that you’re missing the bigger picture, and how its now a war of ecosystems. I get that. This is in part a rant and in part a post on thinking aloud about what could Nokia do to stem the impending bloodbath that the next two quarters would bring.

Nokia has released its Q2 2011 results, reporting an operating loss of -€487 million, with net sales of €9.275 billion (down 7% YoY). Nokia's Devices and Services division's losses were -€247 million. Margins in devices and services were -4.5% (down 14% YoY and down 14.2% QoQ). However, non-IFRS operating profit was €391 million (down 41% YoY and down 44% QoQ), with Devices and Services non-IFRS profit at €369 million, and margins at 6.7%. Total smartphone device sales were 16.7 million, compared with 24 million units in Q2 2010 (down 34% YoY) and 25.2 million units in Q1 2011 (down 31%, QoQ). 

A couple of weeks ago I was notified by Quim Gil that I was selected for the MeeGo Community Developer Device Program for a Nokia N950 devkit.  Prior to this I had been quiet in Maemo-land for a little bit while I worked on an experimental rewrite of one of my applications that uses PyGame.  Seeing as PyGame isn't on the N950 I hurried up in getting it to a state I could put aside and moved on to learning QML.

Lately, I’ve been developing some software which makes an intensive usage of QUrls as resource locators for local files. Nothing wrong here. QUrl is a powerful way of sharing the locations of those in an universal way. The problem is when you construct those QUrls from QStrings and you actually forget that QUrls are meant for much more than representing local file locations.

Last Thursday I received a package containing something called the Nokia N950 development kit. Sweet sweet hardware, shame it's not going to be sold to end users. The software is visibly an unfinished pre-release version, but shows great potential. There are almost no 3rd-party apps, which is why Nokia is loaning these N950s to random developers.

I intend to port GTimeLog to it. Although my more immediate need is to have FBReader, so that I can stop carrying both this one and my N900 with me everywhere. Also, vim would be nice.

I've already hacked up Lithuanian support to the virtual and hardware keyboards, thanks to the very nice design of Maliit. As a comparison, I've had my N900 for a year and a half, and I still can't type Lithuanian on it. XKB is not fun.