Jolla Launch

Jolla has finally launched the first hints to their first hardware. Being an old N9 user, having dropped his phone, I really do want one. The N9 easily outperformed my current Samsung S3, despite its ancient hardware, so I’m really excited about what Jolla will be able to do with modern hardware.

wide_Jolla_devices

The specs are a bit sketchy at the moment, but I guess things might become more clear tonight. For €399 you will bet a 4.5″ Estrade display, a dual core CPU and 4G support (in some markets, which will be announced later). 16GB of on-board FLASH and support for microSD means that there will be ample space for music, photos, videos and applications.

An 8MP camera seems to be commodity today, but the user-replaceable battery is a nicety.

So, nothing about the performance of the CPU, or even the family. I expect an ARM in the 1GHz range, which will be more than double the power, compared to the N9. Regarding the screen, I do hope for a screen as nice as the N9. I’m kind of worried that no resolution is specified, and Google does not seem to know what an “Estrade” screen is – hopefully it is good. As Europe is targeted first, I hope that the 4G standard supported will be LTE and will work in Swedish networks.

On the software side, I’m really excited about the Sailfish OS and the Gestures. This is what the N9 started, and the N9 is the only real one-hand device I’ve experienced. Finally a Qt / QML environment with the ambition to bring something new to the table.

As for Android app support, I’m not convinced. The power of the N9 was the pure performance of native applications. Adding an Android stack will use system resources and experience the same performance penalty that pure Android systems face. Also, I guess “app compliant” does not mean certified, i.e. does Google Play work? Still, there will be loads of apps, so everyone can use their favorite service. I hope that the Android stack is loaded when needed, so that it doesn’t take resources when using a purely native setup of apps.

At the time of writing, I cannot register a pre-order as the site is down. I only get 503. This must be a good sign, I guess ;-).

tt-rss in debian stable

I run a little server of my own with debian stable. Now, I wanted Tiny Tiny RSS, as Google just showed why relying on the cloud isn’t a good thing.

As tt-rss only lives in unstable, I decided to backport it. In order to do so, I had to backport the following packages (in this order):

  • libarchive-zip-perl, which is a build dependecy to rhino
  • javahelper, which is a build dependency to shrinksafe
  • rhino (and thus also librhino-java), which are build dependencies to shrinksafe
  • shrinksafe, which is a build dependecy to dojo
  • libjs-dojo-core (and thus also libjs-dojo-dijit), which both are dependencies to tt-rss
  • prototypejs, which is a dependency of tt-rss
  • tt-rss

I hope I did not mix up what is a build dependencies and install dependencies, but it does not really matter. You will have to apt-get build-dep foo && apt-get -b source foo for each of these. Then dpkg -i foo the resulting debs. You might also have to install some prepackaged stuff, as dpkg doesn’t resolve the dependencies automatically.

Having tt-rss up and running, I migrated my subscriptions from google reader, installed the Android app and waited. The first time, tt-rss gets the whole feed, so you’ll have to wait a while (a couple of hours in my case) and then mark all as read, then everything works nicely.

There are few other cloud services that I depend on as much as a good RSS reader (I tend to read from many different devices, depending on where I am). But it is unlikely that I’ll every again will trust a cloud service as a critical part of my day-to-day workflow. Just look at what happened to tinkercad (which I did not rely on).

Update on Work

As some of you know, I work for Pelagicore. We do in-vehicle infotainment using open source, Linux and Qt. I’m not in Las Vegas right now, but a whole bunch of colleagues are there, showing of at CES.  This year, we’re doing loads of demos together with various partners. We demo together with Visteon (makes infotainment hardware, and more), Digia (makers of Qt), GENIVI (infotainment platform standardization organization), Cinemo (media indexing, rendering and streaming) and Rightware (cool 3D UIs).

IMG_20130108_111108

One of the fun parts of working at Pelagicore is that you get to see cool hardware. I’ve personally worked with Qt on Intel prototype systems, Freescale iMXs, TI’s OMAPs and more stuff that I can’t mention. This year’s demo setup for CES is based on iMX6. The UI has been developed with DesignIt, our design partner company. Let’s face it, those who enjoy coding generally do not excel at polishing pixels. With their help, we’ve been able to make something really beautiful. The picture I’ve got of the UI itself does not say much of the look and feel, but it has a nice reflection of my kind colleague taking the photos, so I’ll use it to say thanks to him and give some credits ;-).

IMG_20130108_111352

The demo is built around Qt and QtQuick (what else is there :-P) on a Linux platform. It integrates our core platform with all the services you might need. For CES, we have some new stuff in there. I have been involved in the integration of technologies from two other companies.

First, we have Righware and Kanzi, a nice 3D engine with an easy to use studio to create the scenes. The car shown below spins around as you change position with nice lighting and material effects. The demo is integrated as an element in the QML scene, and it is possible to bind to and from Kanzi properties, as well as hook into events from Kanzi UI elements, e.g. 3D slides and buttons.

IMG_20130108_111440

The second piece of technology is Cinemo’s media platform. It indexes, renders and streams video and audio. For instance, you can sync multiple devices showing the same video stream, so that you can share the audio through the main speakers. Again, the video stream is integrated into the QML scene, so you can do all sorts of fancy things with it. The images below show an iPad and our demo system sharing a video stream. As you can see, you can control it from either device, and they are always in perfect frame sync.

IMG_20130108_111136+7

From a business standpoint, I guess CES is one of the highlights of the year. We really get to show our stuff to a large audience. However, since I’m not in sales, to me it means overtime, but also having a chance to work with companies making awesome technology. Also, as an added bonus this year, we got to work closely with our team of former Trolls based in Munich, which always is good fun.

So, to all of you at CES. Come visit our demos! To the rest of you, look our for our platform in your next car!

Components Growing

Looking past the irony that QML will be available for all platforms but WP8 in the short-term, and Nokias previous involvement in the development of QML, it is nice to see the platforms being created.

The last in the row is Ubuntu Phone, others are Jolla’s Sailfish, RIM’s BB10 Cascades, KDE’s Plasma and Nokia’s Components for Harmattan and Symbian. Qt seem to unlock the future UIs for devices.

What is striking is the interaction patterns being established. Nokia Swipe, Sailfish as well as Ubuntu Phone seems to rely heavily on swiping from the sides of the screen. This is, in my experience, the key to a truly one-handed device.

Using Android, you are constantly forced to hold the device in awkward angles or use two hands to reach the home button, be it physical or on-screen. Swiping with the thumb is always possible when using one hand (as long as you have an opposable thumbs), while the two-handed user can swipe using the index finger without feeling hindered by the interface.

From a development perspective, it is interesting to see how the different QML Components are shaped. Ubuntu seems to have some interesting ideas for theming going on, and the other platforms have their own strong points.

One interesting comparison is to look at the API for a single component. Comparing the CheckBox elements of Ubuntu Phone, BB10, Harmattan, Symbian and Plasma gives the following API (only looking at the properties and signals that I regard as relevant to the comparison in question).

Properties

  • text (BB10, Symbian, Harmattan, Plasma)
  • checked (BB10, Symbian, Harmattan, Ubuntu Phone, Plasma)
  • enabled (BB10, Harmattan)
  • pressed (Symbian, Harmattan, Ubuntu Phone, Plasma)
  • hovered (Ubuntu Phone)

Signals

  • onCheckedChanged (BB10, Symbian, Harmattan, Ubuntu Phone, Plasma)
  • onClicked (Symbian, Harmattan, Ubuntu Phone, Plasma)
  • onPressAndHold (Ubuntu Phone)

Where does this leave us? For all platforms, one can use the checked property and its onCheckedChanged signal to act. The rest is in up in the air. Ubuntu Phone seems to split the text from the checkbox while the others keep them together. The enabled property is missing from most platforms. Here, even Symbian and Harmattan, both from Nokia, seems to differ.

Still, as the concepts seems similar, the work to create a cross-platform set of components wrapping the components of each platform should not be an impossible task (looking at checkboxes only, that is). Hopefully the end result will not be a too fragmented API landscape and the involved parties will work towards a common setup of basic properties and signals.

Either way, I’m happy seeing that 2012 was a bad year, 2013 looks very exciting. Seeing all these innovative phone user interfaces being created with QtQuick, I’m happy to work at a company innovating in the automotive space using the same technology.

Disclamer! These findings are based on the API docs only. Feel free to correct me by commenting.

Changed behaviour in Qt 5 beta 2

So, I’ve taken the time to shift my development target at work to Qt 5 beta 2 (from beta 1). Most things work perfectly, however, qmake has changed its behaviour slightly – in a subtle evil way.

First, some background. I’m building a QML plugin. When building it with beta 2, it no longer loads as it could no longer resolve the vtable for one of my classes.

$ readelf -sW /home/e8johan/work/prf/lamprey/lamprey/lib/liblampreyqml.so | grep UND | grep QmlAudioHardware | c++filt 
    45: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND vtable for QmlAudioHardware
    47: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::nameChanged()
    50: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::volumeChanged()
   288: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND vtable for QmlAudioHardware
   301: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::nameChanged()
   308: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::volumeChanged()

What was this all about? I looked at the source, commit logs, everything – nothing had changed and everything was in place. Inheritance – check, Q_OBJECT macro – check, file listed in HEADERS in the pro-file – check…

Then I started to look at what was actually built. Apparently not the moc

$ find | grep moc | grep qml
./qml-plugin/build/moc
./qml-plugin/build/moc/moc_qml-plugin.cpp
./qml-plugin/build/obj/moc_qml-plugin.o
./qml-bindings/src/build/moc
./qml-bindings/src/build/moc/moc_http_downloader.cpp
./qml-bindings/src/build/obj/moc_http_downloader.o

Since the software I build worked, I simply built it using qmake && make -j5 and then went for a coffee. When doing qmake -recursive I notices a long list of header files that weren’t found:

$ qmake-qt5 -recursive
...
Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/qml-bindings.pro
 Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/src/src.pro
WARNING: Failure to find: qml_audiohw.h
...

Why?! Apparently, a colleague of mine has already reported a bug, and this is the way that it is supposed to be. I’m not sure that I agree. This totally breaks the point of DEPENDPATH to me.

The fix is easy, so now it works, but I’m not happy with loads of ../include in my pro-files due to the way my codebase is structured. I just wonder if this is what we really want…

Update! and it turns out that, yes, that is really what we do want. Apparently this feature has broken code (VPATH causing the wrong files to be picked up). So this is by design.

Update again! running qmake -Wall -r treats the missing header warning as an error. Highly recommended!

Speaking at Qt Developer Conference

I’ve finally been able to find a time slot to try to summarize the Qt Developer Conference. This year I ended up spending lots of time in our booth, so I’ve visited surprisingly few talks. I’m really hoping that KDAB will be able to sort out the issues that they’ve had with audio, so that they can get them on-line. In the mean time, I’d like to share my reflections of the event. From my own viewpoint, is was great seeing so many familiar faces again. Seeing that the event sold out, i.e. 500+ visitors, was great. I knew that the Qt community was strong, but this is great!

From what they keynotes contained and what people said, I also like the direction that the Qt project is taking. Back to the deploy everywhere is something that I’ve been looking for a long time. I even talked about it at FSCONS last year, even though my topic was Necessitas (which worked too well to do a good tech session on it; what is interesting in install, deploy, run…) Hearing that cross platform is key and that Digia supports bringing it to both iOS and Android during 2013 is great.

Another nice thing is Jolla (not actually on QtDC) and BB10. It is ironic to see that what Nokia saw as a burning platforms is picked as the way forward by two competitors. Let’s hope that they succeed and can show app developers what Qt and QtQuick really can do.

Also, seeing the whole group of service providers working around and inside the Qt project makes me happy. Not only the big ones providing general services around Qt, but also smaller niche players. All are able to live because the productivity boost that Qt gives. Taking Qt to a niche of your own seems to be a great way to build a business.

Finally, I did my speech on the morning the last day. The room was deserted when I arrived, but everything worked. I was even able to convince my laptop to play nice with the projector. I’m happy to say that when I finally got going, it was full. There where even a few people standing along the wall. Thank you all for attending! The slides are on the conference page, but also downloadable from here.

Thanks for everyone making it possible for all the Qt developers to meet in 2012! Let’s all meet again in 2013!

Raspberry Pi

I’ve got a Raspberry Pi since a while back. I placed an order the morning the Pi was released. However, I also have a newborn and a four years old, so progress on the Pi has been slow. Now, finally, I have a setup that I’m pleased with.

I use my Nokia N900 charger, a non-name powered USB HUB, and a d-link DWA-131 wifi USB dongle. This page is a great resource for selecting periphials. The only draw-back right now is that the HUB and Pi draw power using separate supplies. Sharing a single 5V feed would reduce the need to free wall sockets from two to one :-)

For casing, I use a self-printed Raspberry Pi case with GPIO-access. However, I’ve not had time to fiddle around with the GPIOs just yet. The case fits nicely onto my noname USB HUB, so I’ve joined the two using a piece of velcro. The look is not very stylish, but the packaging is nice.

For software, I use the Raspbian image featuring debian built for armv6 with hard-float. I also use the qt50-snapshot from here (look under nightlies). That image is missing qmlscene and qmake, so for development, I guess I have to setup a cross compiler, or spend 4-5 days compilation time building a Qt 5 snapshot on the Pi myself. Not having qmake is sort of ok – compilation times are bound to be long, but qmlscene would had been nice, to be able to do local QML development.

I’ve had Qt 5 working from a snapshot for Debian wheezy with softfloat which had qmlscene pre-built. The framerate is nice, so it felt as if there was true potential there. I’m looking forward to being able to build my own little C++ QML extension and try it out for real.

Pics, code and more info will follow.

Do not dash in deb

When building Harmattan apps using Qt Creator, it is important not to have dashes in your project name. If you do, the generated desktop file will refer to foo-bar, while the app binary and icon will be named foobar. It is a simple fix, but can be confusing at first.

Symptoms: app starts when launching from Qt Creator, but icon looks odd and app cannot be launched on the device.

June 21st 2012

When your wife has been in pain every 15 to 20 minutes for six days and six nights, you appreciate the sincerity when she asks you to take her to the hospital at four in the morning.

Bloodstains in the ceiling of the delivery room. Women are tough!

After a short routine check, we where admitted. Five hours later, Erik, was born.

The day after, we could leave the hospital and go home. His big sister is delighted to have a little brother.

Everything is going well. We are tired, as expected, but my wife is my hero. Give us a couple of weeks and we’ll be back in the game again!