A Quick Look at Extras in Bugzilla
2012-02-27 through 2012-03-04

There is seemingly a trend (in ideas) to use your mobile device as a remote control for stationary devices such as your TV.

We thought that experimental support for remote text input should be easy to add to Maliit, as it already comes with a server-client architecture. As soon as client and server can run on different host machines, we’d have network transparency and it should basically just work. Luckily, we use D-Bus as our IPC, and it turns out that D-Bus understands remote host addresses. If you check the README in maliit-framework you will recognize that – with the latest release (0.90.0) – it only takes an additional environment variable, MALIIT_SERVER_ADDRESS, to connect a client (that is, an application that uses the Maliit input context) to the input method server. The scary part is perhaps that one has to disable D-Bus authentication. Therefore it's a good idea to only use this inside a trusted network.

Jon created a video which demonstrates the new feature in a better way, using a laptop that is connected to a projector as a TV replacement. The great thing about this feature is that it requires no changes to the applications, nor to the Maliit input method plug-ins, it’s the framework that handles this internally (or not so internally, now that Qt 5 turned our D-Bus API into a public one).

However, to make Maliit truly useful as a remote control, at least two additional features are required:

• Have a proxy text editor widget on mobile device that allows text interactions such as copy and paste, cursor positioning and rich text formatting.
• Emulate and transmit mouse or touch events, possibly through a dedicated touch area on the touch screen of the mobile device.

The second feature requires an extension to the Maliit protocol, whereas the first is already filed as bug MALIIT#84. After that, I could use my N9 (or my N900, as Maliit also runs there) to remote control my Gnome or Ubuntu Unity desktop, which would work perfectly for my movie watching habits. Kudos goes to Krzesimir and Jon for their work on this feature.

Permalink | Leave a comment  »

Dear eager N9 developers!

We know that you are interested in updating your devices to PR1.2 as fast as possible, but we propose that you restrain yourselves to the fully productized and verified updating procedure.

The availability of the update is based on the variant of the Harmattan operating system on your device, and not the current operator or your physical location. See Harmattan version numbers explained (23-Jan-2012) for further details.

The over the air updates are rolled out on a per-variant basis. Some variants are released earlier, and others obviously later. The exact schedule depends on various aspects, including but not limited to variant volumes, time zones and e.g. network owner approval. Please have patience waiting for the update notification to appear on your device.

We recommend that you do not apply your skills or other voodoo in forcing the update from the terminal application. While manually tweaking the settings and trying to force the update may seem to work, you may also end up bricking your device or otherwise rendering the platform or applications to an unexpected state.

A variant release consists of packages that have dependencies to each other. Different variants have different packages and different dependencies. Additionally, apt-get is a component of full software delivery stack and using it directly is not advised. If a user e.g. forces an update of a variant on top of another variant by manually tweaking repository information, this may result in some packages not getting updated, and some being otherwise wrong.

To update your device, only use the over the air updates with device graphical user interface or the Nokia Software Updater.

Remember that great powers come with great responsibility: the warning of potentially losing your warranty when enabling developer mode is there for a reason. The terminal enables you to do plenty of impressive things, but it also enables you to mess up your device's configuration and contents in a spectacular fashion.

In addition, some users have experienced sluggishness on first boot after the update. That is to be expected and is a sign of ongoing cleanup and re-indexing. It should be fairly fast, only a minute or so for most users. However, the duration is dependent on the amount of data stored on the device, and thus the sequence may take significantly longer as well.

Front Page

Nokia N9 PR1.2 now available over-the-air

The long-awaited PR1.2 update is now available for Nokia N9 users.

Go to Settings > Applications > Manage applications > Update.

In this edition (Download)...

1. Front Page
   • Nokia N9 PR1.2 now available over-the-air
2. Applications
   • Avoiding jet lag with continuous clock change
   • Daily Wallpaper is Qt Ambassador project of the week
   • Two new FM Radio frontends for N9
   • ...and 3 more
3. Development
   • Mer Platform SDK can now build itself
   • Reverse engineered "WhatsApp" client can send messages
   • Harmattan PR1.2 requires Secure APT repositories
   • Qt Components running on BlackBerry Playbook
4. Community
   • maemo.org Extras Testing/QA refresh
5. Devices
   • Nokia launch WP, Series 40 & high-end camera phones - no sign of Qt for next billion
6. Announcements
   • WiFik - WiFi scanner for Harmattan
   • MaeMeeMo - a MeeGo Harmattan Nemo modification pack for Maemo 5
   • Personal Web Server for Nokia N9
   • ...and 6 more

My N950’s display started to grow black stripes some weeks ago:

The lines are getting longer and thicker day by day. And now an N950 of a friend of mine started to do the same thing. I wonder if this is happening to all of them?

N9 is the only viable option for me with its own pros and cons. Hopefully it won’t disappear too quickly from the shops..

A Quick Look at Extras in Bugzilla
2012-02-20 through 2012-02-26

http://www.developer.nokia.com/Community/Blogs/blog/andrew-fleggs-nokia-developer-blog/2012/02/26/avoiding-jet-lag-using-continuous-clock-change

These days I'm often travelling long distances; whether it's to Asia or Detroit with work; or San Francisco for the MeeGo and JavaOne Conferences.

Ten hour flights are rarely fun; but when combined with a ten hour time difference? The jet lag can destroy you.

However, I trust a clock when I see it. So if I can convince myself that the time isn't changing in one big jump, jet lag is less of an issue. I used to do this with my watch: every two hours on a ten hour flight with an eight hour time difference: move my watch forward two hours. By speeding up, or slowing down time, I find it excellent for transitioning gradually to my destination timezone.

My N9's standby screen provides an opportunity to do this automatically: every time I glance at my phone on the flight, it could show me the right "transient" time.

I prototyped it with a spreadsheet (download), for a recent trip to Korea, to see how effective it would be before writing an app:

 

To try it out, first off, enter the local departure and arrival times; and the timezone difference:

If travelling eastwards, the time difference will be positive. If travelling westwards, it will be negative.

A shell script will then be shown in column E. Copy this column and paste it into a text editor. Copy the resulting script to your UNIX-based mobile device (N9, N950, N900, N8x0, jailbroken iPad).

On a Harmattan device, the script needs to be run in develsh:

~ $ develsh outbound.sh
...

On everything else it needs to be run as root:

Jaffas-iPad:~ mobile$ su -
Password:
Jaffas-Ipad:~ root# sh outbound.sh
...

If run with screen or nohup, you shouldn't even need to keep the terminal open.

NEXT STEPS

Obviously the next step is an app. Is it something you'd be interested in? Is there a nice Qt API for changing the time? Are there Qt APIs for looking up timezones, and setting the device's timezone?

Thanks to eipi for allowing me to use MaeFlight's icon in this post. Also published on Nokia Developer blogs

These days I'm often travelling long distances; whether it's to Asia or Detroit with work; or San Francisco for the MeeGo and JavaOne Conferences.

Ten hour flights are rarely fun; but when combined with a ten hour time difference? The jet lag can destroy you.

However, I trust a clock when I see it. So if I can convince myself that the time isn't changing in one big jump, jet lag is less of an issue. I used to do this with my watch: every two hours on a ten hour flight with an eight hour time difference: move my watch forward two hours. By speeding up, or slowing down time, I find it excellent for transitioning gradually to my destination timezone.

My N9's standby screen provides an opportunity to do this automatically: every time I glance at my phone on the flight, it could show me the right "transient" time.

I prototyped it with a spreadsheet (download), for a recent trip to Korea, to see how effective it would be before writing an app:

 

To try it out, first off, enter the local departure and arrival times; and the timezone difference:

If travelling eastwards, the time difference will be positive. If travelling westwards, it will be negative.

A shell script will then be shown in column E. Copy this column and paste it into a text editor. Copy the resulting script to your UNIX-based mobile device (N9, N950, N900, N8x0, jailbroken iPad).

On a Harmattan device, the script needs to be run in develsh:

~ $ develsh outbound.sh
...

On everything else it needs to be run as root:

Jaffas-iPad:~ mobile$ su -
Password:
Jaffas-Ipad:~ root# sh outbound.sh
...

If run with screen or nohup, you shouldn't even need to keep the terminal open.

NEXT STEPS

Obviously the next step is an app. Is it something you'd be interested in? Is there a nice Qt API for changing the time? Are there Qt APIs for looking up timezones, and setting the device's timezone?

Thanks to eipi for allowing me to use MaeFlight's icon in this post. Also published on Nokia Developer blogs

In short, I now have a Nokia n9, and setup a scratchbox for it, and compiled & installed abiword, clawmotia, unison, and libferris for and on the device. If that didn't enlarge your page down key, the longer version now follows ;-)

One of the good things of QML is that you can have both C++ and QML code and interact between them. For example, from C++, you can access the QML tree and invoke methods, change properties, etc.

The other way around, you can also define C++ objects and interact with them from QML. Here you have two ways of doing it:

• Instantiating from C++ and adding the objects to the QML context, meaning that you can invoke the public slots and access the properties.
• Registering the QML type with qmlRegisterType and then instantiating it from QML.

At the Qt documentation you can find examples about how to implement the different approaches so I won’t talk too much about them and I’ll focus in a special case of the last approach.

Let’s see a QML code like this:

Item {
    id: myObject
    function doCoolStuff() {
        // doing really cool stuff here
    }
    Rectangle {
        anchors.fill: parent
        color: "red"
    }
}

Button {
    text: "Do cool stuff!"
    onClicked: myObject.doCoolStuff()
}

Imagine now that painting that rectangle is something that must be really done by your object, because it is needed and inherent to it, and so is the function. If the code is written only in QML, the answer is obvious, just move the whole Item code to a .qml file and leave the main code like this:

MyObject {
    id: myObject
}

Button {
    text: "Do cool stuff!"
    onClicked: myObject.doCoolStuff()
}

Let’s suppose that you need some C++ code in that object for whatever reason (you want to use some GNOME library, for instance). In this case you need to write it in C++ to define the public slots in that language. Our first step would be something like this:

#include <QtCore>
#include <QtDeclarative>

 class MyObject : public QDeclarativeItem
 {
     Q_OBJECT

// Define some Q_PROPERTY here with its methods

 public slots:
     void doCoolStuff(void);

// We could even define some signals
 };

For the slot, it does not matter if you declare it as slot or with Q_INVOKABLE because QML will see it both ways. Of course, don’t forget to write the cpp file with the implementation for the slot