Nearly two years ago (in April 2010), I ported Brain Party to the N900 using javispedro's awesome SDL_gles library. Having nearly forgotten about it, I "ported" it to Harmattan today - It's even a bit easier with Harmattan's SDL, which includes the necessary changes. The game doesn't pause/silence when put into the background, but the basic functionalities work, including sound.


Download here: brainparty_0.5.91-3_armel.deb (39 MB)
Source here: brainparty_0.5.91-3.dsc / brainparty_0.5.91-3.tar.gz

The game itself has been written by Hudzilla Games, who also published the game for the iPhone and XBox 360 - if you like the game, you can support them by buying the game from there. This port is based on the open source version of the game.

The n9 libferris app now allows you to search by the URL of the file as before, but also now by the file text content and it's modification time. Query type is selected by a button in the top right corner which unfortunately isn't nearly as easy to read in the video file as it is in real life.

As libferris handles extraction, update, and storage of metadata from disparate locations I have also added a sprinkling of what that means into the video. Notice that the first search by URL shows a comment "REST interface to libferris" in bold. This is simply the "annotation" metadata of the file but is much more interesting to the searcher than it's URL. Likewise in the second query, which finds a Gutenburg text file by searhing on text content, the annotation offers the name of the book that the file contains. Again much more interesting content to the human who is at the helm.

The third query is on the modification time of the files. There are three ways offered to perform a time search, "more recently than this" or "than last" which can have month or day as options for example, and modified >= X months ago which obviously wants a number as the query text. When querying by time like this, libferris happily accepts some human readable terms like "begin this month" as the time you specify. This makes it just as convenient to use search in scripts as in the dedicated front ends like the n9 app.



The plan is as always, to push metadata from being an after thought to being a first class citizen: able to be created, read, written, indexed, and searched on. Any file with metadata should be able to expose that as simply as its mtime or size, which is all currently done via a key-value "Extended Attribute" interface at the lowest level.

If you like libferris or the recent updates (status.net mounting, these indexing tweaks etc) then please consider making a donation. If you want to use this technology at a corporate level, please feel free to contact me.

As part of my work at Igalia I am writing an app to record some videos for the Nokia N9. I wanted to get them shown in the gallery so I tried the DBUS approach, that is something similar to what is explained here. The problem is the same they faced, meaning that I got gallery in foreground when it was not previously running, but not otherwise.

The solution to that was using libcontentaction. In order to get this working, first you need to get the vendor name in the tags of your pictures or videos, otherwise Tracker will not index them correctly and this solution can be useless.

With the following solution Gallery will be brought to foreground and show the desired file. Code would be something like:

using ContentAction::Action;

[...]

{
    Action action =
        Action::defaultActionForFile(uri,
            "x-maemo-nepomuk/device-captured-video");
    if (action.isValid()) {
        qDebug() < < Q_FUNC_INFO << "chosen action:" << action.name();
        action.triggerAndWait();
    } else {
        qWarning() << "could not file action for" << m_file;
    }
}

The mime type is one of the defined in the galleryserviceaction.desktop that you can find in the device. For images, you can also check the mime types in that file and maybe you do not need to specify it, but I have not tried this and let it to you. Please, comment me your findings.

Firefox for Mobile Device Proximity - http://dougturner.wordpress.com/2012... March 22, 2012 from DougT » mozilla - Comment - Like

Continuing my n9 apps I now have an index search app that uses libferris. Currently I have only exposed URL regular expression search. This is searching an index maintained and stored in a PostgreSQL database. Solving regex query in a timely manner is a fairly complex problem with one useful solution outlined in one of my previous blog entries.

Note that data is downloaded over normal http(s) from the server using the n9 app, so no NFS or other network mounts are needed. This might be handy for grabbing a PDF, image or text file off an Intranet file server while on the move.



I have also been updating the clucene libferris module to allow more effective index use during regex/infix queries. This libferris engine works quite nicely on older ARM machines. Benchmarks on that to follow, once I reindex the arm and produce the comparative figures.

I've been meaning to write about this for a while, but I've only just now been driven over the edge by having to go and basically run sed over code again for no good reason.

As you know (and it's already reported), there's currently no way to import an OPML into the Nokia N9 Feed Reader application (see Harmattan Bug #159).

However, I noticed that when you open a feed link with the built-in browser, it launches the Feed Reader app, and asks you to subscribe to the feed. I guessed that it was communicating with the Feed Reader using D-Bus, so I dbus-monitored it, and that's what I found:

1. First, the browser asks the application to subscribe to a given feed (here I'm asking the client to subscribe to my blog's feed):
   

   dbus-send --print-reply --dest=com.nokia.FeedReader \
   / \
   com.nokia.FeedReader.subscribeFeed array:string:"http://simonpena.com/blog/feed/"

2. If the user accepts that, then the Feed Reader application requests the Engine to actually subscribe to the Feed. The nice thing is that, although you cannot (AFAIK) ask the client to subscribe to more than one feed at the time, you can ask the Engine to do it, so this actually works (requesting the engine to subscribe to my blog, Planet Maemo and Planet Igalia):
   

   dbus-send --print-reply --dest=com.nokia.FeedEngine \
   / \
   com.nokia.FeedEngine.subscribe \
   array:string:"http://simonpena.com/blog/feed/","http://maemo.org/news/planet-maemo/rss.xml","http://planet.igalia.com/atom.xml" \
   string:"rssatom"

From this point on, it should be quite straight forward to import an OPML into the Feed Reader application. You can use a QDomDocument to parse the OPML or use QML's XmlListModel to parse the OPML file.

XmlListModel {
    property string subTitle: ''

    query: subTitle ? "/opml/body/outline[@title='" + titleText + "']/outline": "/opml/body/outline"

    XmlRole { name: 'text'; query: '@text/string()' }
    XmlRole { name: 'title'; query: '@title/string()' }
    XmlRole { name: 'type'; query: '@type/string()' }
    XmlRole { name: 'xmlUrl'; query: '@xmlUrl/string()' }
    XmlRole { name: 'htmlUrl'; query: '@htmlUrl/string()' }
}

Then, you can use this to subscribe to the feeds using D-Bus:

static const QString DBUS_IFACE("com.nokia.FeedEngine");

void Controller::subscribeFeeds(const QStringList &feedList) const
{
    QDBusInterface dbusInterface(DBUS_IFACE,
                                 "/",
                                 DBUS_IFACE,
                                 QDBusConnection::sessionBus());

    dbusInterface.asyncCall("subscribe",
                            QVariant::fromValue(feedList),
                            QVariant::fromValue(QString("rssatom")));
}

I hope you find this useful

Smoke the Bugs is now available to download from Nokia Store for Harmattan N9 and for Anna/Belle. No bugs (except software bugs!) were harmed while developing the game, but to know whether this virtual bug smoking is suitable for you, check this video of game play on N9:



As explained here earlier, this was partly an expedition on making a game with pure QML + JavaScript + shader effects. Plan was to make it totally without C++ (excluding the launcher which Qt SDK generates automatically) and to see what the outcome would be.

So summing up some random development notes here:

• Harmattan version of the game utilizes Qt-components for portrait main window and for disabling swipe while playing. Symbian version does not use Qt-components as pure QML was enough.


• It's good to use Loader for separating rest of the UI from initial "splash screen" for faster startup. Another option on Harmattan would be to show static splash screen image with invoker.


• In this game, loaders are also used for help and high score views. As these are not often used, it is better to save memory and only load them when needed. Loading is fast enough not to cause notable delay.


• ShaderEffectItem is available on Harmattan, Belle and Anna+Qt 4.7.4, so it's possible to target quite a many devices. Exception is Nokia 500 which is lacking GPU for OpenGL.


• With Symbian, setting QGLWidget for viewport is required to be able to use ShaderEffectItem. On Harmattan this is not needed as the default graphics system is already set to use OpenGL.


• When application is minimized, unload ShaderEffectItems or set their 'visible' property to false. Not doing this causes minimized application to use resources unnecessarily. Application state can be tracked with Qt.application.active


• When writing shaders, be careful to keep them performing well. Symbian devices and especially newer Belle ones can handle heavy fragment shaders better than N9. As an example, moving night effect math from fragment shader to vertex shader improved performance notably on N9.


• Avoid too many ShaderEffectItems to save resources. As an example, instead of each bug containing its own burning effect, there are three global effect items in a queue, positioned and animated when needed. If three simultaneously burning bugs are not enough, it's easy to add more effect items into queue.


• QML performance notes give good general guidelines what to avoid. Qt5 version of this document is even better and provides also information on how Qt5 scenegraph and V8 engine changes reflect to optimizing QML performance.

P.S. I joined Nokia ~month ago which may increase my bias towards Qt... But it's not like I wouldn't have made my opinion pretty clear already ;-)

Xournal for the N800 and N810

Some days ago I was writing about how to have mixed QML/C++ objects in a QML application for Igalia, but I faced a problem with the code that I had written. And the problem was that I needed to receive some events and from the QML elements I was loading. Retaking that code:

#define QML_PATH "/path/to/the/qml/files/"

MyObject::MyObject(QDeclarativeItem *parent = 0) :
    QDeclarativeItem(parent)
{
    QDeclarativeEngine engine;
    QDeclarativeComponent component(&engine,
        QUrl::fromLocalFile(QML_PATH "MyObject.qml"));
    QDeclarativeItem *rect =
        dynamic_cast(component.create());
    rect->setParentItem(this);
}

and being MyObject.qml something like:

Button {
    id: "myButton"
    text: "Do something cool"
}

The natural way of connecting that button to some slot you are writing would be something like:

MyObject::MyObject(QDeclarativeItem *parent = 0) :
    QDeclarativeItem(parent)
{
    QDeclarativeEngine engine;
    QDeclarativeComponent component(&engine,
        QUrl::fromLocalFile(QML_PATH "MyObject.qml"));
    QDeclarativeItem *item =
        dynamic_cast(component.create());
    item->setParentItem(this);
    connect(item, SIGNAL(clicked()), this, SLOT(doCoolStuff()));
}

Even if you do this, you are not getting any event in the QML button you declare. It behaves as it were a label or whatever, but the key is the engine. The engine must live while you need the events of the QML component. And the easiest way of getting that done is adding the engine as a private class attribute:

#ifndef MYOBJECT_H
#define MYOBJECT_H

#include 
#include 
#include 

class PostCapture : public QDeclarativeItem
{
    Q_OBJECT

// ...

 private slots:
    void doCoolStuff();

 private:
    QDeclarativeEngine m_engine;
};
#endif

and of course removing the engine stack declaration from the constructor:

MyObject::MyObject(QDeclarativeItem *parent = 0) :
    QDeclarativeItem(parent)
{
    QDeclarativeComponent component(&m_engine,
        QUrl::fromLocalFile(QML_PATH "MyObject.qml"));
    QDeclarativeItem *item =
        dynamic_cast(component.create());
    item->setParentItem(this);
    connect(item, SIGNAL(clicked()), this, SLOT(doCoolStuff()));
}

Voilà.

Of course, if you need to connect to any element that is not the root element, you can always forward the signals and properties from the QML root object or just use the QObject::findChild method to access the right component.