In my previous blog I had introduction to MeeGo 1.2 Harmattan Qt Quick components, in this blog I  wrote about porting components to other platforms than MeeGo 1.2 Harmattan and in next one about porting applications to different Qt Quick Components like MeeGo-Ux, Symbian or desktop.

Nokia N9 device will be largest volume MeeGo device in near future and most interesting platform for MeeGo application developers.  Portability of  Harmattan components is interesting issue for many reasons. N950 developer devices are produced only limited quantity and N900 provides excellent developer platform that is more easily available. Many MeeGo developers would like to see their application to run other MeeGo devices and would like distribute their application for all of them. Harmattan components are licensed as BSD license, so they are free to distribute any platform.

MeeGo 1.2 Qt Quick components are portable code but there is some issues need to taken care when porting them.First one is that components use Qt Quick 1.1 and most platforms like Ubuntu Natty or MeeGo 1.2 still have Qt Quick 1.0. I have made patch set allowing components to run in Qt Quick 1.0. This is problem is just temporary, and vanish  soon when MeeGo and Ubuntu upgrade  up to date Qt version in next release.  

Second issue is theming. MeeGo 1.2 Harmattan SDK comes with Nokia MeeGo 1.2 Harmattan product theme that is same theme used in production device, N9. This theme is Nokia proprietary. It may be used in software development but it can't be redistributed. When you make applications for N9, this is no problem because theme is factory installed in N9. If you would like distribute your applications to other MeeGo or even non MeeGo devices, you need to use theme that allows redistribution.  Standard MeeGo 1.2 uses MeeGoTouch theming that is based on .svg files having multiple graphics elements in one file. Qt Quick uses .png BorderImages. To use components, I have exported graphics elements as .png files and made separate add on package. Now developers have two choices, if they would like just develop for N9, it is recommend to use Nokia “blanco” theme, if intention is to distribute application to other platforms, you should use open theme based on MeeGoTouch “base” theme or other compatible theme.

Third issue is different UX. The UX between MeeGo 1.2 handset, MeeGo 1.2 tablet and MeeGo 1.2  Harmattan. There is a big difference to end user, MeeGo 1.2 Harmattan has magnificent swipe UI where task switching is done by swipe gesture. MeeGo 1.2 handset uses traditional way to have close button in application toolbar and MeeGo 1.2 Tablet uses hardware home key. The great advantage of Harmattan Swipe gesture is that no valuable screen space is wasted for home button and toolbar and there is no device front surface wasted for home button and larger amount of device front surface can be used for display and actual application. My experience of MeeGo tablet is still based on keeping one tablet in my hand 5 minutes. For application code difference is small. In MeeGo 1.2 handset application should initiate itself task switching but minimizing it's window. In MeeGo 1.2 Harmattan and MeeGo 1.2 tablet, task switching activity is initiated by external process as result of swipe gesture or pressing home button. If we compare to typical desktop applications, application switching, minimizing and closing window is initiated by external window manager application. Close and minimize buttons are in desktop in window frame that is owned by window manager, not by application. Maemo Hildon used same method, tittle bar was owned by system process. In MeeGo, all screen is owned by application and if there are home and close buttons, application should respond to them and initiate action. Other small difference is that in MeeGo 1.2 Handset and MeeGo tablet, toolbar is at top of the window when in Harmattan it is at bottom. At summary differences:

• MeeGo 1.2 Harmattan: Toolbar at bottom, no close or home buttons needed
• MeeGo 1.2 Handset:Toolbar at top, Home and Close buttons needed
• MeeGo 1.2 tablet:Toolbar at top, no Home or Close buttons needed

What that means in practice to application developer ?

You can use Harmattan components to develop applications to all MeeGo devices. With small effort you could adapt your application UI to MeeGo 1.2 handset or MeeGo 1.2 Tablet. At minimum, you need only to add Close and Home buttons to MeeGo 1.2 Handset applications. Your applications would look like more consistent to other system applications when you move toolbar to top of the screen and to redistribute your code for non N9 environment you should use free “base” style.

ToolBar location

In Harmattan UX, the toolbar is located on bottom of screen, in MeeGo handset or MeeGo Tablet, Toolbar is located on top of screen. By default toolbar location is hardwired to bottom in Harmattan components PageStack.qml , I made small experimental patch, adding property toolBarOnTop that defaults as false. Setting this property true, you will have toolbar on familiar place in MeeGo 1.2 handset or tablet. Remember, that property, toolbarOnTop is not standard, do not try use it in Harmattan.
 

Home and Close buttons

In Qml To have Home and close buttons in your toolbar, you should add them to toolBarLayout. In front page you should have home button in left corner and close button in right corner. In other pages there should be back button in right corner.  Qml does not directly support minimize or close, you need to have hooks in your C++ code to server slots. Add following lines to your main QdeclarativeView

 

   QDeclarativeView window(QUrl("qrc:/main.qml"));
    window.rootContext()->setContextProperty("mainWindow",window.window());
    QObject::connect((QObject*)window.engine(), SIGNAL(quit()), &app, SLOT(quit()));  

Your Main page  .qml file could look something like this. In harmattan, you don't need toolbar in main page at all unless you have menus or some other need for it and you can omit tools: from mainpageComponent. Commontools is commont toolbar definition that is used in all subpages.

PageStackWindow {
    id: rootWindow
    initialPage: mainpageComponent
    toolBarOnTop:true // Experimental non standard property

    ToolBarLayout {
       id: commonTools
       visible: false
       ToolItem { iconId: "icon-m-toolbar-home"; onClicked: mainWindow.showMinimized();}
             ToolIcon { iconId: "toolbar-back"; onClicked: pageStack.pop(); }
        }

 Component {
  id: mainpageComponent
  Page {
    id:mainPage
    tools:
     ToolBarLayout {
      ToolItem { iconId: "icon-m-toolbar-home"; onClicked: mainWindow.showMinimized();}
      ToolItem { iconId: "icon-m-toolbar-close"; onClicked: Qt.quit(); }
     }

Equivalent version for Harmattan is

PageStackWindow {
    id: rootWindow
    initialPage: mainpageComponent

    ToolBarLayout {
       id: commonTools
       visible: false
             ToolIcon { iconId: "toolbar-back"; onClicked: pageStack.pop(); }
        }

 Component {
  id: mainpageComponent
  Page {
    id:mainPage

 

Some desktop/mobile related porting issues

Most of developers develop applications in desktop first and them move to real device or emulator. Harmattan Qt components work without problems on desktop. It defaults window size as 854x480. To render window correctly in MeeGo 1.2 or Harmattan environment, window must be created as full screen with window.showFullScreen(); in desktop this is annoying of your test application window pops upp full screen 2560x1600 size with small patch of content in middle. In Harmattan components this was resolved just easy way

#ifdef __arm__
    window.showFullScreen();
#else
    window.show();
#endif

This works in Nokia devices but is not so nice for x86 based touch screen devices. Some little bit more clever way is needed. I made code so that that it just takes size of screen and it it is smaller or equal 1024x800, assume touch device and use full screen, if it is larger, render into window. I made also patch in mdeclativescreen.cpp so that it uses screen size as default size if running smaller screen than 1024x800.
Here is full main program with handling close and minimize and setting full screen in small displays.

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    QDeclarativeView window(QUrl("qrc:/main.qml"));
    window.rootContext()->setContextProperty("mainWindow",window.window());
    QObject::connect((QObject*)window.engine(), SIGNAL(quit()), &app, SLOT(quit()));

    QRect screenGeometry=QApplication::desktop()->screenGeometry();
    if((screenGeometry.height()<800) && (screenGeometry.width()<1024))
         window.window()->showFullScreen();
    else window.window()->show();

    return app.exec();
}

Release Notes for MeeGo 1.2 Harmattan Qt Quick Components ports

The current base package is qt-components – 1.0~git20110620-7-1fn, it is available now for Ubuntu Natty and MeeGo 1.2 arm and x86 targets.  If you would like to use experimental version of MeeGo 1.2 graphics and not Nokia Harmattan product graphics you can down load extra theme graphics  , qt-components-base-icons-0.3 . If you are running in non-MeeGo environment you need also to install meegotouchtheme package. If you would like develop for N9 with product graphics, I recommend to use graphics delivered with MeeGo 1.2 Harmattan SDK (QtSDK) or Platform SDK (Scratchbox)

You can get MeeGo 1.2 Harmattan Qt Components port for Ubuntu from Forum Nokia PPA qt-components - 1.0~git20110620-7-1fn

sudo add-apt-repository ppa:forumnokia/fn-ppa

sudo apt-get update
sudo 
apt-get install qt-components qt-components-base-icons meegotouch-theme

For MeeGo 1.2 , arm and x86 components are located in: http://repo.pub.meego.com/home:/kate/DE/  .


MeeGo arm version is tested on N900 Community Edition, x86 version for tablet is mostly untested, may be just my bad luck setting environment. Qemu image just freezes after few minutes and chroot Image Xephyr died in few seconds.....

At teh moment, code is only in my personal repository but i hope that we get them soon some more convinient repository. At the moment, download files and install them with rpm comman. When we get files to repository, use zypper

zypper install qt-components qt-components-base-icons

Maemo5 packages will be soon in maemo extras-devel repository.

Chanegs to original git version 

•     Works witn Qt Quick 1.0
•     Autodetect “base” and “blanco” themes
•     environment M_THEME_NAME specifies used theme when multiple themes are present
•     Use full screen size when unde 1024x800 , original was fixed 854x480
•     toolBarOnTop property to PageStackWindow
•     qt-components-base-icons extra icons for base theme

Nokia has just released our new great MeeGo 1.2 Harmattan device, N9, it is a developer device N950 and Harmattan SDK beta release. New Qt Quick components library is now part of Harmattan SDK for N9 and N950 devices. When I had my previous blog about Qt Quick components in November 2010, components were just at very early development stage. Nokia moved development as closed in January 2011 because we started to develop them for new great UI concept that you can now see in our N9 and N950 devices.

The new UI concept has only very minor effect to actual application code. Task switching is now done by swipe gesture and no home button is needed any more. Swipe gesture handling is provided by framework and it does not need anything from application side, you just does not need implement “Home” button to return task switcher any more. Because home and close buttons are not needed, you don't need have toolbar in your page unless it is needed by menus or back button in stacked pages. Toolbar is also moved to lower side of the screen that is more natural place for it when used by finger.

This release of components implements rich set of UI elements and the required part of our N9 UX. Compared to November 2010 release, there is for example full support for dialogs. API has also evolved a lot better since. The good thing is also that now components do not need to be linked into application Qt Code, just use standard QDeclarativeView or you can test your components UI with QmlViewer.  New components comes also with new product quality graphics and they are no longer depending in MeeGoTouch framework to serve  graphics and styles. Technically, any environment that Run Qt 4.7.4 or newer should be able to run Harmattan Qt Quick Components.  Nokia Developer former Forum Nokia will provides a community port of components to Ubuntu Natty, Maemo5, and MeeGo 1.2. New components could be easily adapted for example to MeeGo 1.2 style with just small hack in application.

Our Qt Components are licensed with Open Source license, so you are free to use them in any system. Out product theme that comes with MeeGo 1.2 Harmattan SDK is proprietary but I have made version of MeeGo 1.2 theme that works with MeeGo Harmattan Qt Components. I will provide more information about porting to different platforms and community theme in my upcoming blogs.

Because Nokia was developing new Harmattan UI, we kept development of components closed several months. At same time Intel also did their MeeGo-UX components development closed. For that reason, API's of these two MeeGo Qt Quick Components are not  fully compatible.  Situation is still not so bad at all, I will handle more about this UX differences and porting between these different Qt Quick Components and between different UX in my next blog that will be published soon.  the porting between toolkits is simple and straightforward, it took just under hour to port my AR-Drone application to use also MeeGo-UX component.


Short introduction to  Nokia MeeGo Qt Components

This does not try to be any comprehensive programming guide for MeeGt Qt Components.
At first, set of screenshots from QlmComponentsGallery demonstrating available UI elements. Application works automatically in Portrait and Landscape orientations. You can find general Qt Quick Components API definition  from http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200

Let's first look our our demo application .
QmlComponentsGallery main page is PageSatckWindow with ToolBarLayout. The Page content is standard Qml LisView  element with Elements linking to new PageStack pages.

QmlComponentsGallery Main Page

 

Buttons

Menu

Sliders

TextFields

Dialog

QueryDialog

DatePicker

 

Using MeeGo 1.2 Harmattan components

To use components in your application, you need import com.nokia.meego 1.0  and then use PageStackWindow as your main level element. Under Page Stack window you should define your ToolBarLayout what tools you have visible in default toolbar and then put your main page to initialPage. If you don't have menus in your application, you could omit “toolbar-view-menu” and menu related form toolbar. Notice that in Harmattan you don't need close or home buttons because they are handled by swipe gesture by window manager. You can either have MainPage as separate Qml file that is then loaded as component or you could just have it included in same main.qml with “component” definition.

import QtQuick 1.0
import com.nokia.meego 1.0

PageStackWindow {
    id: rootWindow
    property int pageMargin: 16
    initialPage: MainPage { }

    ToolBarLayout {
        id: commonTools
        visible: false
        ToolIcon { iconId: "toolbar-back"; onClicked: { myMenu.close(); pageStack.pop(); } }
        ToolIcon { iconId: "toolbar-view-menu"; onClicked: (myMenu.status == DialogStatus.Closed) ? myMenu.open() : myMenu.close() }
    }
}

As example main as in file compoent

Component {
      id: mainPage
      Page {
        tools: commonTools
     …. Put Flickable, ListView etc here as body …..   
   }
}

When you would like to open new page, just use pageSatck.push() like here we open from button press new page that is inline component catComponent. Button is standard button component from MeeGo Harmattan Qt Components.

Button {
             height: 50
             width: 600
             text: "Show a cat"
             onClicked:(pageStack.push(catComponent))
           }

Dialogs are now also supported in components library. You have either standard general purpose Dialog component or specialized variants QueryDialog, SelectionDialog and MultiSelectionDialog. Standard Dialog has three fields: title, content and buttons.

Dialog {
    id:myDialog2
      title:Label   { color:"blue" ;text:"myDialog"}
      content:Label   { color:"white" ;text:"Content Comes Here"}
        buttons:Button {id: bOk; text: "OK"; onClicked: myDialog2.accept()}
    }

To display this dialog, use myDialog2.open() . Technically you could populate dialog content with Flickable element with a long list of components and use it as same way as dialogs are used in desktop. In Handset environment, if you have a long content, it may be better to use Stacked pages than dialogs and use Dialogs only for shorter content.

Porting to MeeGo 1.2 Harmattan Qt Quick Components

There are not many applications done with November 2010 pre-release of components but many things about porting affect also applications done with other toolkiits like MeeGoTouch.

In my blog How to make modern Mobile applications with Qt Quick components I had an example application skeleton, catapp . I made this application with both Qt Quick components and MeeGoTouch. Application itself is just UI elements demo but I used about same structure in my AR-Drone application.


Main screen has toolbar on top of screen and it had Home and Close buttons. These buttons were required by framework to be able to close application or return to tack switcher.

Same main screen with new components does not need toolbar at all because task switching is done by swiping gesture and also closing is managed by task switcher.


As a small detail, buttons are not in the middle but aligned to top because content pane is a Flickable element. There you could add any amount of content and scroll it by finger.

There is also two buttons to display dialogs. One shows same dialog than originall application as sliding window. Even we have now also support for Dialog objects, least as my opinion this method is better when your dialog has a lot of content.  This sliding window has a toolbar because “back” button is needed to return main page. Toolbar is located to bottom of screen as required by MeeGo 1.2 Harmattan style.



There are now native dialogs and they are excellent when you have less content than this application.




Developing with MeeGo 1.2 Harmattan Qt Quick Components

By default, after you have installed QtSDK 1.1.2  with MeeGo 1.2 Harmmattan plugin, you can develop for Harmattan Qt Components either with real N950 developer device or with Qemu Harmattan device emulator. N950 devices are manufactured only very limited quantities and very few developers would have one. If you don't have actual device, you should use Harmattan System QEMU image. Good thing in Qemu is that it runs same software as device, bad thing is that it does not match in performance with native execution.

For experienced Linux developers we have also Scratchbox based Harmattan platform SDK. With Platform SDK you can compile and run your code in Harmattan software environment compiled as native x86 or ARM code, bad thing in scratchbox is that it is more complicated than Qt SDK and intended only for experienced Linux developers.

After you have installed Qt SDK, If it does not yet have Harmattan target. You should install it using updater. Chose from “Help” menu “Start Updater”. In updater, chose “Package Manager” tab and ten enable “Harmattan” target under “experimental”

Nokia developer, former Forum Nokia is offering three other alternatives. Ubuntu native Harmattan Qt Quick components, MeeGo 1.2 N900DE version of components and Maemo 5 version of components are coming soon. We are also looking MeeGo 1.2 tablet and Macintosh native components. Using development system native components is fastest and easiest way to develop and debug application but it has limitations that there many handset specific API's are not available.  Development system native components is also easiest way to study and evaluate MeeGo  1.2 Harmattan Qt Quick components.

Installing Nokia Developers Community port MeeGo 1.2 Harmattan Qt Quick Components

Harmattan components require Qt Quick 1.1 but MeeGo1.2, Ubuntu and Maemo5 has support only Qt Quick1.0 . For Qt Quick 1.0 Components sources needs some patches to make work, I made patched set that would be available for Ubuntu from our FN PPA. For N900DE you will have qt-components.rpm package that will be released soon.

FN PPA will have soon ready made debian package for Ubuntu Natty, just ad ppa

sudo apt-add-repository ppa:forumnokia/fn-ppa
sudo apt-get update
sudo apt-get install qt-components-dev qt-components-examples

To run Harmattan components applications, you need also theme graphics. Our Harmattan SDK has graphics included. The graphics are Nokia proprietary, so you are not allowed to redistribute them. For that that reason, we are not including packages to our PPA or MeeGo repositories. For debian based Ubuntu or Maemo 5, you could just copy meegotouchtheme.nokia-graphics.deb and meegotouchtheme-nokia-icons.deb and install them with dpkg -i command.

sudo dpkg -i meegotouchtheme.nokia-graphics.deb meegotouchtheme-nokia-icons.deb

If you can't use these debian files, you can use scp -r or cp -r to copy files from your SDK to your host. Files should be  /usr/share/themes/meego/blanco directory tree from SDK to your target system. Under scratchbox it is located in /scratchbox/users/<your_user_name>/targets/HARMATTAN_X86/usr/share/themes
In your QtSDK they are located at QtSDK/Madde/sysroots/harmattan-arm-sysroot/usr/share/themes/

cp -r ./QtSDK/Madde/sysroots/harmattan-arm-sysroot/usr/share/themes/blanco /usr/share/themes/

We are working for open freely redistributable graphics for Qt Quick COmponents  based on N900DE "base" theme. I am hoping that we could make this available soon.

 

Main view with live feed from AR-Drone camera and telemetry


Here is a little hcking project that I am releasing just before Christmas, it is something fun to play around, something that really moves and makes also non-hackers exited. It also allows to you use own imagination to enhance this base application to be even more fun. Least to me, Christmas has been always time to build something that is fun,like all kind on flying gadgets. I still like playing with everything that flies, some ones where I can sit myself in pilot seat and someone that I can control remotely.
I decided to combine work and fun and also offer a super-cool possibility to learn MeeGo and Qt Quick with having fun, just go shop and buy AR-Drone 299$ and download code from http://mardrone.garage.maemo.org and have happy hacking.
 
After Nokia announcement focus Qt and Qt Quick and after my previous blog howto make modern mobile applications with qt quick components there has been a lot of need for some real life full show case applications how to do UI with Qml and how to use existing C++ application logic. We have also here in Nokia term “dogfooding”, we should eat own dog food that we make. In his Qt Quick / Qt Components in the case I should say that it's the best dog food I have ever had.

Other goal for this application has been show, how easy is to make MeeGo versions of iPhone applications. Original Ar-Drone FreeFlight application was made for iPhone. Making Qt Quick UI for this application takes just day or two. Current UI still looks like engineer's tool, because it is made by an engineer. To make it really good looking needs touch of UI designer and great graphics but no SDK can solve this problem even it is iPhone, Android or MeeGo. Integrating C++ code to Qml took less than days work.  The more detailed anatomy of this application is coming on second part, next blog entry.

There has been also criticism and rumors that Nokia would be killing Maemo and no-one should any more develop for Maemo. I would like to prove all these rumors to be wrong. The best option today is to develop with maemo5 with Qt and Qt Quick and when a MeeGo handset is released, just deploy your application for it, it is that easy.

You should remember that our Harmattan project started as called Maemo6 but after merging to Intel Moblin it became MeeGo. Maemo and Moblin already had common roots and result of this merge was not incompatible what Maemo6 was. I have compiled and run this same application without changing a single line of code in both N900 with Maemo5, our future MeeGo based device and Ubuntu Lucid in desktop. Your application will run on all platforms unless you intentionally chose some obsoleted API's like GTK+ based Hildon. For someone that does not like EOL of some old API's I recommend reading my previous blog entry, we just needed to renew our UI technology to be competitive and as application developers you should be happy that we can provide now best application development platform where your imagination is only limit in UI creation.

AR-Drone and application

Technologies, that I use in this AR-Drone application are: All QI Is Implemented with Qt Quick QML Language and MeeGo Qt Quick Components with addition of some my own QML and C++ components. I have integrated to the UI seamlessly some my existing Qt GraphicsView code as custom component and existing C-code, AR-Drone video codec used in iPhone and in their GTK+ demo application. All application logic is coded with Qt / C++ . Application uses real time and performance critical things like live video feed from drone camera, real time telemetry data from drone and augmentation of video with realtime HUD display.

What is then the AR-Drone ? AR-Drone is quatrocopter, Vertical Take off and Landing ( VTOL) aircraft, rotorcraft like helicopter. Quadrocopters are not so efficient for cross country flying they are very simple to construct with electric motors and due simplicity they are very crash proof and durable. With implementing artificial stabilization with software and sensors they can be made very easy to fly and handle. Typical RC-helicopter may need dozens of hours, many dozens of crashes, disappointments, lot of glue and hundreds of euros. As opposite, AR Drone, you just press fly button and it starts hover about one meter over ground and then you can start moving it.

Technically AR-Drone is much more advanced than standard RC-aircrafts. It has 32 Bit ARM processor running Linux, it is controlled over WLAN and it has bi-directional data stream transmitting back both telemetry data and live video feed from two cameras on drone. For flight control AR-Drone does have 3 axis MEMS Gyro ( angular speed sensor) and linear acceleration sensor, ultrasound for measuring altitude and bottom facing camera for position holding.

AR Stands for augmented reality and it's manufacturer, Parrot calls it as flying video game. You can implement as example air fight between two drones by detecting others color tags from video and augmenting video image with ammunition trails or misles. I my application I did not yet try to make this kind of game but i have already augmenting layer implementing HUD ( Heads Up Diaplay) , similar than fighter planes have showing flight instruments over pilot's vision.

This is not a sponsored add, i just bough my AR-Drone from Sunnyvale Bookstone shop with $299.

Basic structure of application

The main program is very simple, it just registers my three C++ classes to Qml and then creates QdeclatariveView with my main Qml file, ardrone.qml. For easier application packing, it uses Qt resources to keep qml files, so no extra files is needed to install with application. The ardrone.qml then imports my “drone” classes with import Drone 1.0 . 

Main class is called by DroneControl, it does not have any visible representation to Qml, it's purpose is to implement actual application logic and expose it's interface to QML. DroneControl creates instance of  DroneThread that handles real time control and telemetry connection with drone. DroneControl class also implements interface to QSettings for application settings storage.
DroneControl also implements command protocol and telemetry data parsing. They are implemented from scratch with Qt, i had option to use also AR-Drone SDK VP_LIB library functions but they had so heavy dependencies that i did not like and the command protocol was so simple that i decided that it is easier just do own implementation with Qt/C++

As addition to main Logic, I created class DroneVideo derived from QGraphicsWidget . For Qt C++ view it is just like any other QGraphicsWidget derived class that can be used to Qt QGraphicsView applications. It did not need any modifications to be used as component from QML. Standard QGraphicsWidget properties like position, size etc are already automatically exposed to QML. That means that you can use your QGraphicsWidget or QGraphicsItem derived classes in many cases without any modifications from QML. The DroneVideo implements video streaming functionality via separate VideoThread. It was easiest way to implement this application and re-use codec from AR-Drone SDK. In future more elegant solution would be to implement codec as Gstreamer module. The DroneVideo is not yet optimized at all, in future I should also consider implementing YUV-RGB conversion and scaling with GPU OpenGL-ES2 and shader code. Performance currently in N900 is fair but even this implementation gives relativelly good performance in MeeGo device.

Third C++ class I used, was also re-use from my previous Qt QGraphicsView based application implementing HUD, Heads Up display, artificial horizon with declination and inclination indicators.  It was mostly as it is, but just non-standard properties exposed to QML with Q_PROPERTY declaration. HUD is drawn as overlay over video picture. If yoy would like to add some augmented reality stuff like gunfire, missles etc, just replace HUD drawing code with it. You could also use Qt OpenGL-ES2 if you need more compled Augmented reality.

The actual UI is implemented with Qt Quick and Qt Quick MeeGo Components. The main QML UI file is under 200 lines of code, specifying layout of main screen of application and binding UI element properties to C++ class variables. Main page is mostly custom UI in full screen mode, more like games are but it uses MeeGo Qt Components framework and some items like Button and Text there. Joysticks are implemented as my own QML components. If you need some custom UI component, in  many cases you can do it with 10..50 lines of QML. The settings page is implemented as separate page less than 200 lines. For easy application deployment, all qml files are included to executable code as resources, so no extra directory is needed for them.

Building application

To build application, you need to have Qt 4.7 and Qt Quick components installed.  You can read from  howto make modern mobile applications with qt quick components how to install them for both Ubuntu and Maemo5 Scratchbox development environment. You don't need to use Qt Creator but if you would like to use it, you can read it from qt creator and scratchbox .

My application source code you can get from http://mardrone.garage.maemo.org with git.

git clone https://vcs.maemo.org/git/mardrone

To addition, you need AR-Drone SDK that contains video codec library for AR-Drone from
https://projects.ardrone.org/  

You need to apply patch ARDroneLib.patch from mardrone to compile AR-Drone libraries under scratchbox for Maemo/MeeGo target and to expose couple of previously static functions to application. The AR-Drone SDK were unaware that you could compile for ARM target under Linux that looks a like “native” ARM that does not look as embedded linux.

If you would like to build test version of this application for both desktop and Maemo/MeeGo target
and do it automatically from Qt Creator from same source directory, extract your AR-Drone SDK for both your Ubuntu host and scratchbox under your home directory. They are in real life different directories and so you can have x86 in host and ARM under your scratchbox. To build, execute under your host and scratchbox both

cd ARDrone_SDK_1_5_Version_20101004/ARDroneLib/Soft/Build/
make

To build actual application, you can either just open ardrone1.pro file with your Qt Creator and
press run, it should compile it with your host Qt4.7 . Compiling under scratchbox from Qt creator, please refer previous blog. Or you can just compile it from command line

qmake
make

If you would like to make installable debian package:

fakeroot dpkg-buildpackage -b

And you should have ready made application to run. If you have installed it from debian package, you will have ready icon. If you would like to run it fron command line, In  current pre-alpha N900 Qt Quick components MeeGoTouch style libraries there is bug that you should start your application with

mardrone -graphicsystem native 

That is slower than opengl but with opengl render you got all components as red background.

Using using application with AR-Drone

WARNING this application is at the moment early alpha level, version 0.1. It is intended to be used as technology demo and suitable only hackers that can read, understand and fix the code. There are still unknown bugs and unimplemented features like acceleration sensor, joystick, better UI style etc. Don't try this unless you know what you are doing.

When you have your drone, i recommend to first test flight in place where you have free space around but not in windy weather. Best place is big empty room like garage etc. The drone should auto-hover after takeoff and it if crash resistant, so it should not get easily broken if you collide walls etc but try avoid it.

First step, you should connect your device to AR-Drone Ad-Hoc WiFi network. After powering up your drone., you should see network named ardrone_xxxxxx, connect to that one. It should assign IP 192.168.1.2 to your device and drone will be 192.168.1.1 .

The next step is to start mardrone application. It takes little moment and you should see application main window. If the connection to drone is successful, you should see video feed from drone camera. If you see gray background with X, over it, there is no video feed and no connection to drone.

By default you should also see two lines of green text over joysticks. They are debug status from drone. If there is something wrong in your drone, you should see message there. As example, if you carry it by hand, it may have too high angle and you get message there. You can reset status by pressing emergency twice.

To fly the drone, press “fly” button on bottom of the screen. The drone should take off and hover about one meter over ground. It should not move to any direction without you controlling it with joysticks in left and right side of screen. Try first right joystick, it moves drone up, down and turn around. When you are familiar controlling, try right one, it makes drone to fly forward, backward, left and right. Be careful, with full deflection drone flies fast and may collide something.

 

Happy Hacking

What Ui toolkit I should use for mobile application development has been a top issue since Maemo5/Fremantle SDK alpha release. There were two choices available, GTK+/Hindon and Qt. The amount of choices has been increased since then and caused a lot of confusion among developers.

Many developers would like to continue to use their old familiar UI toolkit, GTK+/Hildon, QWidgets or Symbian Avkon but there is many reasons reconsider your choice and look at a new toolkit Qt Quick and Qt Quick Components.

To find reasons, we should look 30 years back into history. The modern desktop Graphical User Interface story begins from Xerox Palo Alto Research Center, PARC. Most of basic inventions like mouse, desktop metaphor and windowing system with overlapping windows were made there. Modern Desktop GUI matured to it's current state with first Apple Macintosh release 1984. You can read more about the history from http://en.wikipedia.org/wiki/History_of_the_graphical_user_interface .

After these days, there were no major changes in Desktop GUI paradigm, we had standard UI elements like overlapping windows, pull down menus, scrollbars, dialogs, buttons etc all same form that they are today. There were multiple toolkits with lot of different APIs implementing the same elements. We had Mac and Windows native toolkits and several toolkit variants for Linux/Unix. Qt toolkit, first version released 0.90 was released 1995, offered common cross platform QWidget API for GUI programming.

There was a major UI paradigm shift in 2007 when the first iPhone was released. The old desktop metaphor with mouse interaction was abandoned and a new one introduced. Scrollbars, overlapping windows and mouse-sized UI elements were gone and replaced with sliding windows, scrolling from content pane and widgets designed to be used with finger. iPhone was the first successful touch screen device that was sold with high volumes. Before that, there were numerous touch screen devices on the market, both pocket sized and laptop or pad form factor but none were successful.

All these old generation touch screen devices were still using old desktop UI paradigm and touch screen was just a mouse replacement. In most of the cases it needed to be used with a stylus to provide mouse-like pixel accurate pointer. The idea was good but users just did not like it.

N900 with Maemo5, announced 2009, was the first Nokia device with a new finger based UI paradigm. Maemo5 had finger optimized UI components, sliding stacked windows, kinetic scroll from content pane, all implemented top of desktop-oriented toolkits, GTK+/Hildon and Qt/QWidgets. The new Mobile UI needed a lot of modifications to these toolkits that did not become adopted upstreams implementations as those were still focusing solely on the desktop. Maemo5 implementation was also based on support from tailored window manager for window transitions and stacked windows, enhanced X11 keyboard protocol was used for the virtual keyboard. Also, none of these enhancements were adopted to upstream and Maemo5 toolkit extensions run only under the Maemo5 environment

Maemo6 that later become MeeGo, was started from a clean sheet. Enhancing legacy toolkits, GTK+/Hildon or QWidgets, were insufficient to implement leading edge mobile user experience. The UI toolkit should be based on QGraphicsView/QGraphicsItem rather than old QWidgets. The new approach allowed us to take control of UI elements, transitions and animations inside of the toolkit. Now we had a possibility for a lot more complex animations in element level, animated dynamic layouts etc. There were three parallel development paths inside of Nokia, C++ based Orbit for Symbian, MeeGoTouch for MeeGo and a totally new concept Qt Quick with QML. For the first MeeGo timeframe MeeGoTouch was the only available toolkit and it was used for all basic MeeGo applications.

Qt Quick was part of Qt4.7 released October 2010. The Qt Quick can be considered revolutionary step in UI implementation, even complex UIs were possible to implement with a few easy lines of Qml code. Qml is also easy to learn for UI designers used to work with web UI tools.

The basic Qt Quick contains only Qml that could be considered as a low level UI toolkit. It supports basic low level elements like rectangles, images, mouse areas etc but it did not contain UI components by itself. If you are using plain QML you need to implement UI components by yourself. That is not a problem in many applications that are using their custom UX and UI style but it is wasting time if you just would like to use system UX with system style and standard UI elements. The Qt Quick Components project was introduced to produce ready made Qml UI elements library for Qt Quick. Current status of components project is pre-alpha for MeeGo but it still offers basic UI elements and it evolves quickly. Qt Quick components are also on their way for Symbian and desktop UX.

Our choices

Now we have all pieces together for UI puzzle and we just need to put them together and make our choice. Many may still think that old toolkits like GTK+/Hildon and QWidgets look like attractive choices. Nokia has dropped support of GTK+/Hildon, but QWidgets you'll find everywhere, they run on all desktop platforms and they run on major Nokia platforms. Porting old desktop application with QWidgets looks to most like the  logical solution, you could use same codebase and cover Linux desktop, Mac, Windows, Maemo5, MeeGo and Symbian.

Even if the choice looks attractive, there are two major drawbacks. First of all, if you are porting from desktop, you need full refactoring of your UI. Desktop metaphor is just so different than mobile that it just don't work. This has been tried and it does not work for multiple reasons starting from screen size, resolution and UI element sizes that are different. You just don't have room for large toolbars, forms etc. and using of tiny UI elements with finger is impossible.

The second major issue is that mobile enhancements to these legacy toolkits were not adopted upstream and they are not cross platform. Even if you find QWidgets in every platform running Qt, only Maemo5 supports variant that allows implementing fairly good mobile user experience. In other platforms, you fall back more or less basic desktop implementation that's usability in mobile device is very poor. Also due to differences between the mobile platform implementations and their behavior, the same code may work in a very unexpected way.

 

 

Choice is clear, Qt Quick

 

The choice is clear, if you would like make your application success in Mobile, you should use new UI toolkits designed to meet the mobile requirements. At the moment there are three toolkits available, MeeGoTouch, Qt Quick with plain Qml and Qt Quick Components.

MeeGoTouch is mature but it is not cross platform and not recommended for new application implementation.

Qt Quick should be considered as the preferred future way, it is a part of standard Qt4.7 and exists in all platforms including desktop, Maemo5, MeeGo and Symbian. Qt Quick is clearly the way that I recommend to developers. Then there is still one question open, use just plain QML or be early adaptor of Qt Quick components ?

Qt Quick Components

The Qt Quick components project, http://qt.gitorious.org/qt-components, is currently as pre-alpha in a rapidly evolving phase. It is developed as MeeGo handset UX as pilot platform but Symbian and desktop UX are on their way. Even MeeGo components are still early stage, they already offer fairly good set of MeeGo UI elements and allow implementing most parts needed of MeeGo handset UX. There are still some UI elements that are not yet implemented and for the existing ones, APIs are not yet frozen so you should be prepared to do changes to your QML code when first released version is published.

MeeGo UX Qt Quick components are currently available ready to use debian packages for Desktop Ubuntu Lucid and Maveric, MeeGo/Harmattan ( .deb format) and for Maemo5/N900 as .deb format. You can start developing applications for MeeGo today, just by downloading these development libraries. Even if the there will be API changes before released version, changing some lines of your QML code is a much smaller task than completely redesigning and reimplementing your UI code once again.

How to start

Following examples are not intended to be comprehensive course or documentation of Qt Quick components but just a source of inspiration and also to demonstrate how low the threshold is, even with someone without any Qt Quick Qml experience, to start coding with the Qt Quick Components.

Easiest to start development is to install Qt4.7 and Qt Components to your Desktop Ubuntu from Forum Nokia PPA.

sudo add-apt-repository ppa:forumnokia/fn-ppa
sudo apt-get update
sudo apt-get install qt-components-dev libqtm-dev libmeegotouch-dev

You can find more instructions about installing and setting up Qt4.7 for your Qt Creator from Attila Csipa's blog http://qt-funk.blogspot.com/2010/10/fresh-from-oven-qt-extras-for-ubuntu.html

To make your first application with Qt Quick components, you could use following Qt main program:

#include <qapplication.h>
#include <QtComponents/qdeclarativewindow.h>
#include <qdir.h>

int main(int argc, char **argv)
{
  QApplication app(argc, argv);
  QDir::setCurrent(app.applicationDirPath());
  QDeclarativeWindow window(QUrl::fromLocalFile("main.qml"));
  window.window()->show();
  return app.exec();
}

Compared to a Qt/QWidget application, you just should declare QDeclarativeWindow and show it. In this first example we don't try to interface it by any other way than with our C++ code.

Next step is UI code with Qt Quick Components. Compared to plain Qt Quick Qml application, our main element is now Window, not Rectangle and under window we implement our application UI inside of Page objects. In the first example we created just an one page but later we add more of them. Inside of this page we just create one Button component that is already in our components library and we don't need to code it in plain QML. We put couple of Buttons inside of Column just making easier to add more of them later.

import Qt 4.7
import com.meego 1.0

Window
{
  id: window
  Component {
    id: mainpageComponent
    Page {
     id:mainPage
     Column {
       anchors.centerIn: parent
       spacing: 10
       Button {
         height: 50;width: 600
         text: "Show a cat"
         onClicked:(window.nextPage(catComponent))
       }
       Button {
         height: 50; width: 600
         text: "Show a dialog"
         onClicked:(window.nextPage(dialogComponent))
       }
    }
   }
  }
  Component.onCompleted: {
  window.nextPage(mainpageComponent)
  }
}

To compile this application, we need also .pro file

TEMPLATE = app
QT += declarative
LIBS +=-lQtComponents
# Input
SOURCES += main.cpp
OTHER_FILES += \
main.qml

Then just press “run” from your Qt Creator and this you should see, you get your application with MeeGo style and all MeeGo window decorations.

For real application we need more pages and settings dialog with scrolling list of option widgets. Current Qt Quick components does not yet have dialogs that you can populate yourself but in MeeGo many times sliding pages are already used to implement same function. For this application i implement two pages one with just Image content and other being as “settings dialog”.

Settings dialog, I out content inside of QML Flickable element that implements surface with kinetic finger scrolling and then Column object for children component geometry as I did in the main page. I populated this dialog just for example with Buttons, LineEdit,CheckBox and Switch.

Component {
   id: catComponent
   Page {
     id:catPage
     Image {
       anchors.centerIn: parent
       source: "aureo600.jpg"
     }
   }
}
Component {
   id: dialogComponent
   Page {
     id:dialog
     Flickable {
       id: dialogscrolarea
       anchors.top: parent.top
       anchors.bottom: parent.bottom
       width: parent.width
       anchors.leftMargin:50;anchors.rightMargin:50
       contentHeight: dialogcontent.height
       contentWidth: parent.width
       Column {
         id: dialogcontent
         anchors.left:parent.left;anchors.right:parent.right
         anchors.leftMargin:50;anchors.rightMargin:50
         spacing: 10
         Button {
           text: "Button 1"
           width: parent.width
         }
         LineEdit {
           id: line1
           width:parent.width
           anchors.left: parent.left; anchors.right: parent.Right
           promptText: "Enter text here"
         }
        Button {
           text: "ToggleButton"
           width:parent.width
           checkable:true
        }
        CheckBox {
           id: cbox
        }
        Switch {
           id: switch1
        }

Running this example, you should get the following result. Now you have two application pages with sliding page transitions and you have dialog content with kinetic scroll.

This all is with MeeGo style and MeeGo UX, behaves just as MeeGo applications should be. If you compare this with QWidgets. In Maemo5 you can implement same function with QWidgets but you don't have Switch, in MeeGo Qt you get basic widget style and kinetic scroll but you don't have any way to implement sliding stacked windows. Symbian Qt4.7 does not implement kinetic scroll, neither sliding windows nor multiple windows of any kind.

Maemo 5 and N900

The Forum Nokia has also released Maemo5 version of Qt Quick Components package. Thanks to Antonio Aloisio. You can just compile this example application with Maemo5 PR1.3 Qt4.7 and our qt-components library from extras-devel and you will get exactly the same looking application. MeeGo style differs a little bit from Maemo5 native but even with this small difference, these applications will have excellent usability on N900. It should not be too big task to hack code little bit and make variant of components library that has mostly same style than Maemo5. Only fundamental difference is that MeeGo applications implement sliding page transition by toolkit, Mamo5 with Window manager and for that reason, window tittle bar is here rendered by toolkit, not window manager and that explains the different look of the home and back button. 

Install qt-components for your maemo5 scratchbox. You need to have extras-devel repository /etc/apt/sources.list

deb http://repository.maemo.org/extras fremantle-1.3 free non-free
deb http://repository.maemo.org/extras-devel fremantle-1.3 free non-free

At the moment we have only ARM version, no X86 version because qt-components depends on libmeegotouch on theme engine and libmeegotouch is available only as an ARM binary for Maemo5.

[sbox-FREMANTLE-ARMEL:~]>fakeroot apt-get install qt-components-dev

To install qt-components to your N900, you need to have extras-devel repository enabled in application manager and then use the terminal or ssh:

sudo gainroot
apt-get install qt-components qt-components-examples

The current N900 version of qt-components-examples does not yet have desktop files so you need to run them from the command line. There is also a known bug that you need to run all components examples with -graphicssystem native -option. The current version is developers pre-alpha but I hope that we can soon deliver a version with desktop files and with these known bugs fixed.

~ $ /opt/qt-components/gallery/gallery -graphicssystem native

Using Qt Components from C++

You may have your application logic made already with C++ and you may be just considering about implementing a mobile UI. Or you are planning a new application and you would like it be easilly portable for desktop and different mobile environments like MeeGo and Symbian. You can implement all application logic as usual in C++ code and change your UI layout just loading a  different QML file. You may even implement the same application binary that can implement handset, tablet and desktop UX just loading a different QML file. The key element for this is to make your C++/Qt application interfacing with your QML code. Signals and slots are the easiest way, you may call slots of your C++ code directly from the QML code. If you would like to make C++ variables visible to Qml you can do it with Q_PROPERTY macro. The Following example tells more.

The class itself is just as it was in C++ application, it implements graphical UI element and for that reason it inherits QgraphicsWidget and implements paint and boundingRect functions. It has just one slot for receiving signal from our QML code. No single line of modifications is needed to the original C++ code. Only change that is needed is to expose float property called “value” to our QML code. We need to specify set and get functions value() and setValue(float) for this variable. The variable is read/write one for Qml code but if we would like to make our Qml code doing some actions when this value is changed, we could specify also NOTIFY signal for it. In our case, this value is only used to change value displayed in our element so, no notify is needed. That's all needed to modify your C++ classes to work with Qt Quick Components UI.

class GaugeLabel : public QGraphicsWidget
{
   Q_OBJECT
   Q_PROPERTY(float value READ value WRITE setValue)
 public slots:
    void testClicked();
 public:
    explicit Gauge(QGraphicsItem *parent = 0);
    void paint(QPainter *painter,const QStyleOptionGraphicsItem *option, QWidget *widget);
    QRectF boundingRect() const; void setValue(float val_); float value();
}

To use our C++ classes from our Qml code, we need add one line to our example main program, qmlRegisterType.

#include <qapplication.h>
#include <QtComponents/qdeclarativewindow.h>
#include <qdir.h>

int main(int argc, char **argv)
{
  QApplication app(argc, argv);
  qmlRegisterType<GaugeLabel>("Efis", 1, 0, "GaugeLabel");
  QDir::setCurrent(app.applicationDirPath());
  QDeclarativeWindow window(QUrl::fromLocalFile("main.qml"));
  window.window()->show();
  return app.exec();
}

And then we can use our class from QML as any QML component, we just need import it like here as import Efis 1.0 . Then in code we just use it as object as any QML native object and we can spefify it's size and coordinates. Line value:valueSlider.value*3 binds value returned Slider component named valueSlider. Our C++ class setValue(float) is automatically called every time than we move the slider and value displayed by our C++ component changes automatically when slider is moved. In Button component we specify onClicked that calls a slot from our C++ class.

import Qt 4.7
import Efis 1.0
import com.meego 1.0

Window {
   id: window
   Component {
     id: mainpageComponent
     Page {
     id:mainPage
     GaugeLabel {
      id: gb
      x:200;y:200;width:100;height:40
      value: valueSlider.value*3
      gaugeStyle:16
      name: "MiuMau"
    }
  Slider {
    id:valueSlider
    x:350;y:200
  }
  Button {
    id:testButton
    x:350;y:250;width:160;height:40
    text:"TestButton"
    onClicked: { gb.testClicked(); }
  }
 }
 }
  Component.onCompleted: { window.nextPage(mainpageComponent); }
}

Final result looks a like this:

Conclusion

Qt Quick with Qt Quick Components is the best choice for implementing new mobile application UI today. Qt Quick Components is at pre-alpha phase at the moment but it is already usable for starting application development. We have currently only MeeGo UX supported but it runs on the desktop, Maemo5 N900 and MeeGo. You can get the latest build done by Forum Nokia from our PPA and maemo extras-devel repository. When you start development with current pre-alpha, you can count on that there will be API changes. Symbian and desktop UX comes later. Interfacing Qt Quick Components UX to your Qt C++ code is very easy and when all UI is in the QML code, changing the UX is very easy.

 

Links:

 

http://qt.gitorious.org/qt-components

http://qt-funk.blogspot.com/2010/10/fresh-from-oven-qt-extras-for-ubuntu.html

https://launchpad.net/~forumnokia/+archive/fn-ppa

http://doc.qt.nokia.com/4.7/qtquick.html

 

Qt Creator and Scratchbox

 

Qt Creator is perfect tool for Qt application development, it is first IDE that i have fallen love and even as old hacker I have been ready to trade my old emacs to it. These is one missing feature that so many has asked from me, scratchbox support. It may be one of most requested feature among advanced Maemo/MeeGo developers. Currently QtCreator from Nokia SDK does not support Scratchbox toolchain. Most of current experienced Maemo developers prefer scratchbox because it allows also development of complex applications that are using in Linux build tools and it allows running application under simulated ARM or x86 environment with full Maemo library and style support. From picture above you can see exatly same application run under simulator and under scratchbox.

Getting Qt Creator supporting scratchbox is not so difficult, it just needs some small tweaks.

Make Paths symmetric

First make your paths symmetric under scratchbox and host Linux environment. That means that if your application path is /a/b/c/d under host, it is found under same path under scratchbox. I do this normally doing symlink my directory scratchbox under scratchbox home directory under /home/kate/scratchbox, so path to my application should be /home/kate/scratchbox/myapp under both scratchbox and host Linux.

You can do it with following command on Linux host.

mkdir /scratchbox/users/$USER/home/$USER/scratchbox
ln -s /scratchbox/users/$USER/home/$USER/scratchbox scratchbox

VMWare issues

If you are running your scratchbox under VMWare virtual machine, you may want to have your working directory under host filesystem so that files are available also from your host side. This should least work under Linux and Mac hosts that both share common unix filesystem schematics. As example in Mac, I have under my Mac home directory subdirectory scratchbox that is mounted under my virtual Linux host as /mnt/hgfs . Under my VMWare Linux, i have from my Linux home directory symbolic link scratchbox -> /mnt/hgfs/scratchbox .

To have write access you need to have also matching UID's in both sides. Under Mac OSX default user is 501 but under Ubuntu it is 1001. To get matching user ID, you should make your user under Ubuntu have this same UID 501. By default system is not allowing it but you can change FIRST_UID to 500 and LAST_SYSTEM_UID as 499 in /etc/adduser.conf

To get this same VMWare host directory visible under scratchbox, you also need one extra step. Scratchbox is chrooted environment and it sees only files inside of chroot jail and this mount should be bind-mount to be visible by command

mount -o bind /mnt/hgfs/scratchbox /scratchbox/users/kate/home/kate/scratchbox

Compiler Scripts

To compile, you need to create under your Linux host two shell scripts /usr/bin/sbox-qmake and /usr/bin/sbox-make as follows

/usr/bin/sbox-make

#!/bin/sh
/usr/bin/scratchbox -d $PWD make $@

/usr/bin/sbox-qmake

#!/bin/sh
/usr/bin/scratchbox -d $PWD qmake $@

You also need make them executable by

chmod 755 /usr/bin/sbox-qmake /usr/bin/sbox-make

Easy way to do it is use following cut and paste friendly way

 

 echo '#!/bin/sh' >/usr/bin/sbox-qmake;echo '/usr/bin/scratchbox -d $PWD qmake $@' >>/usr/bin/sbox-qmake;chmod 755 /usr/bin/sbox-qmake
echo '#!/bin/sh' >/usr/bin/sbox-make;echo '/usr/bin/scratchbox -d $PWD make $@' >>/usr/bin/sbox-make;chmod 755 /usr/bin/sbox-make

Create Scratchbox Qt version under Qt Creator

Under Qt Creator, you should go under projects, select desktop target because maemo target does not allow you to chose custom Qt version. Select desktop targer, section General, give configuration name, as example Sbox-qt, Choose “Manage” from Qt Version line and open Qt version management dialog. There, press “+” button and enter as “Version Name” sbox-qt and as “qmake Location” the location of your sbox-qmake script location /usr/bin/sbox-qmake . If everything went right, you should see text “Found Qt version 4.7.0 using mkspec linux-g++ (Desktop)”

 

 

When you return to “Build settings” page, your “Build steps” qmake should be already correct sbox-qmake. Make is still just “make”, you should select “details” from Make and set “Override make” as /usr/bin/sbox-make .

 

 

 

That's all, if everything went correctly, you could go back to your project and select form menu “Build” and “Build project: your project name”. It should build it under scratchbox and parsing error messages should also work.

Running under scratchbox

For running your application from scratchbox, you need /usr/bin/sbox-run script, there is little trick here. Qt Creator expands symbolic links, so /home/kate/scratchbox becomes /scratchbox/users/kate/home/kate, scratchbox run-standalone.sh script does not like that kind of path, so prefix need to be removed

/usr/bin/sbox-run ( for fremantle )

#!/bin/sh
/usr/bin/scratchbox -d `echo $PWD| sed -e "s_/scratchbox/users/[A-Za-z0-9]*/_/_"` run-standalone.sh $@

You also need append export DISPLAY=:2 to end of your scratchbox .bashrc, following cut and paste friendly way

echo export DISPLAY=:2 >>/scratchbox/users/$USER/home/$USER/.bashrc

When all this is done, start your Xephyr from Linux host by

Xephyr :1 -host-cursor -screen 800x480x16 -dpi 96 -ac &

and under scratchbox

af-sb-init.sh start

Under your Qt Creator prohject, go to "Run" settings,  Add "Custom executable" and there sbox-run and name of your executable asargument.

Now you can run your Qt application under scratchbox just pressing green run symbol from your Qt Creator.

Using Host Qt Creator under Mac

Because Mac OSX is Unix based, it is with certain limitations possible to compile under VMWare scratchbox with little tricks. These instructions are not complete and you may need your own expementing to get them work. You need to do same thing, make paths symmetric. Under Mac OSX users home is /Users/<username>, and you need maka same symlink under scratchbox.

You can run scratchbox commands under VMWare using ssh, so make following versions of sbox-qmake and sbox-make scripts, replace kate/kathy as your username and virtual machine IP with your one.

/usr/bin/sbox-qmake

#!/bin/sh
ssh kathy@172.16.109.212 "scratchbox -d $PWD qmake $@"

/usr/bin/sbox-make

#!/bin/sh
ssh kathy@172.16.109.212 "scratchbox -d $PWD make $@"

You also need to set up your mac ssh public key under VMWare Linux .ssh/authorized_keys .

VMWare has nasty feature to change your virtual machine address in fly and these scripts have address as hard coded, more advanced scripts could take this address automatically or then we need find option from VMWare not to change address.

Before setting new Qt target you should create on mac host empty directory /usr/include/qt4 and copy /usr/share/qt4/mkspecs from your scratchbox to mac host filesystem. May be advanced scripts could tweak paths returned by sbox-qmake -query to point under virtual machine but tahat's future project. I have also tried “headless” scratchbox support using Mac OSX Xephyr as display but leas in my tests Xephyr has crashed. It may need building from sources up to date Xephyr but that's also possible future project. Advantage in Headless version is that VMWare appliance is completely hidden behind QtCreator.

Using Qt Creator host under Windows

No hope

 

 

TpSession, simplified Maemo5  Messaging API

There has been numerous questions and requests from developers about how to send and receive SMS with Maemo 5. There was even lot of rumours that  the API is not public. I decided to do something for issue, find out  non documented API's and write examples how to do SMS. After starting work, i soon noticed that there is nothing secret, everything needed was already documented and it was possible to do with documented API's but it was just a complicated and time consuming task that needs deep understanding how Telepathy Framework works. Writing just an example code expanded to project write simple to use API that allows SMS sending with just couple of lines code.

Memo Telephony and Messaging API is based on Telepathy framework . Telepathy supports many protocols, for example Cellular, SIP, IRC, GoogleTalk, Skype about you just name it. The good thing in Telepathy is also that it separates client and protocol implementations. New client protocols can be added dynamically to system. For example, in Maemo 5, you can just install IRC, Skype or many other protocols with application installer without needing any change to client applications using these services. Clients and elements implementing protocols, called as connection managers are communicating with Dbus. There is no need to link protocols to applications or no need applicatins to support protocol plugins. Telepathy allown also multiple client applications co-exist simultaneously.

Telepathy supports Python, Glib or Qt API . My decision to go wiith Telepathy-Qt4 was clear, Qt is the toolkit in Maemo that has the future. It should be first choice to anyone starts new Maemo applications today. 

After I started my Simplification API project, i got involved QtMobility port for Maemo 5. Qt Mobility is full cross platform framework that covers much more than just SMS and messaging. It supports also as example system information, sensors, location, contacts, configuration variable storage, multimedia etc. QtMobility shoud be mumber one choice to access these system services, it has continuity and it is already fully cross platform. QtMobility early Beta or Technology preview for Maemo 5 will be released very soon but it has very limited functionality in SMS/messaging area and there is not yet telephony API at all. It will have full functionality and API set in the near future.  I ended using my TpSession library implementing SMS/IM Functionality for Maemo 5 for QtMobility.

I decided to go on publishing  my TpSession as it is, stand alone library because there is immediate need for it and it allows easy to access to full Telepathy-Qt4 feature. TpSession is community supported API, it is not part of official Maemo content. It is available from Extras-dev repository or you can just take source, link it statically to you code or even use it as "copy and paste" example code how to use Telepathy-Qt4. Teletaphy-Qt4 is also in extras-devel and it will be part of Maemo 6.

How simple is TpSesison

If you just want send a SMS, two lines are needed

TpSession* tps =new TpSession("ring",true);
tps->sendMessageToAddress("ring",”+555666777”,”Telepathy session is for you”);

If you should also receive one, you need just connect one Signal-Slot pair and handle signal 

connect(tps,SIGNAL(messageReceived(const Tp::ReceivedMessage &,TpSessionAccount *)),
            SLOT(onMessageReceived(const Tp::ReceivedMessage &,TpSessionAccount *)));

..

void TestProg::onMessageReceived(const Tp::ReceivedMessage &msg,TpSessionAccount *acc)
{
  qDebug() << "MessageReceived " << msg.text() << "from " << msg.sender()->id();
}

With TpSession you can do also many other things like get indication of incoming call, fetch list of your contacts from IM services, check their presence status etc.

TpSession is at the monent early 0.1.2 version, it works but there is work to do. It is Open, Open Source LGPL project. If you wold like to see new fearteres on it, you can join the project and contribute code.

 

 

 

 

 

 

 

Implementing User interface that looks and feels like Native Maemo 5 Hildon UI needs more than just basic features like Input method or Hildon styles.  In Maemo version before Maemo 5 this basic set was sufficient and most of User Interface was implemented with stantard widgets familiar from desktop.

Maemo Qt follows same path. Qt for Maemo 4 had just this minimun Maemo feature set, Input method, Maemo Menus and Maemo Styles. Maemo 5 had complete UI style renewal. All UI is now finger operable. UI Design has been very successful in this goal. I don't remember when I last time used stylus with M900 despite it has been a long time main devive for my daily use.

The basic widget set from desktop with minimum Maemo additions is no longer sufficient for good Hildonized UI for Maemo 5. The first Maemo 5 Qt released February 2009 was about direct Maemo 4 Qt port for Maemo 5 Alpha SDK. Following releases added more and more Maemo 5 specific UI components. New Maemo 5 app menus, finger scrollable areas, stacked windows, some widgets needed more modifications than was possible to do with just applying style.

Qt 4.5.3 for Maemo 5 with this enhanged Maemo 5 support was relased as beta together with Maemo 5 SDK 1.0 version just before Maemo Summit 2009. Technology preview version of Qt4.6 for Maemo 5 as released about same time. The 4.6 version was in this time just pre-alpha version with just minimum Maemo support, just like Qt4.5.3 was in February.

Now Maemo Qt4.5.3 is settling up for it's final version for PR1.1 release and Qt4.6 is soon ready it's first alha release.

Before this Q4.6 pre-alpha release it was not possible to make any porting guide how to implement Hildonized applications and how nsure maximum portability from 4.5.3 to 4.6. My Maemo Summit 2009 presentation just introduced basic elements needed to implement Hildon style UI with Qt4.5.3. For Maemo Developer days in Copenhagen in November,  I had enhanced version of this presentation with many coding examples but porting guide to Qt4.6 was still missin because some important API's for 4.6 was not yet written.

After Qt4.6 pre alpha became available, I updated document to current version, now it shows API's with example code so that it works with both Maemo Qt4.5.3 and Qt4.6.  You can find download here maemo_qt_devday_2009_1.2.pdf and dialogtest2.tgz

Short summary: To make Qt Application compatible with Maemu 5 UI you need redesign some parts of UI. Input method and Hildon styles takes care that basic functionality works. In Maemo 5, there is no more hierarchical menus but app menus that can be used with finger. You just need to design flat menu layout with few items that they fit on screen. Menus do not add any new API, you just need to remember to make flat menus. Dialogs should be made as finger scrolled list, not desktop style forms. Remember also that Hildonized widgets are much larger than desktop counterparts. Finger scroll API differs little bit between 4.5.3 and 4.6. You should put one line of code inside #ifdef Q_WS_MAEMO_5 to make your code compatible with both versions.  Stacked windows are other key element in Hildon UI. Qt4.5.3 used Multiple QMainWindow instances to create automatically stacked windows. In Qt4.6 you need explicitly set Stacked window atribute. Once again, one line #ifdef solves the problem. My example program is made so that it compiles and works with both Qt versions.

You can safely install Qt4.5.3 and Qt4.6 to same Scratchbox target and in same device. To compile for 4.5.3, just qmake;make and compile for 4.6 /opt/qt4-maemo5/bin/qmake;make .

Happy hacking with Qt!

Maemo summit in Amsterdam 9..11.10.2009 colelcted nearly 400 maemo developers. Qt was clearly one of main themes as addition to N900 and Maemo 5/Fremantle and some advance information about Maemo 6 Harmattan.

There was several presentations about Qt, i had presentation with tittle Qt for Maemo 5 , maemo_qt_maemosummit_2009_1.0.pdf. I covered in my presentation roadmap of Maemo Qt,Maemo Qt port and portting Qt applications for Maemo. There was also same time announcement  Qt4.6 fort Maemo and Nokia announces official Qt port to Maemo This caused lot of confusion and I try clarify situation little bit.

Maemo Qt history starts from Nokia 770 times when i made first Qt3.3.4 port but this did not lead anywhere. When Nokia announced beginning of 2008 acquisition on Trolltech i quickly realized that we need to have Qt for Maemo. In these days, Maemo Diablo was GTK+ based and there was no intention to have Qt at all. Forum Nokia decided to support Maemo community for Qt port and we hired Antonio Aloisio (GNUton) as lead developer summer 2008. We continued Maemo Qt development together with open source community. Special thanks to Kimitake, David Greaves(lbt), Timo Härkönen, Andrew Olmsted(fiferboy), Eetu Lehmusvuo and many others from OSS community. We released and maintained Qt port for Maemo Diablo during 2008 . We released Qt 4.5 port together with Maemo 5 (Fremantle) alpha SDK 2.3.2009 . Summer 2009 Qt4.5.3 port was tested and integrated to Maemo. When Maemmo 5 final SDK was released, Qt 4.5.3 was integrated. Four core Qt4.5.3 libraries are already in device flash and others downloadable from apps repository. The next step is obvious, Qt4.6 was in technology preview state and now Nokia Qt Development Frameworks announced that they are integrating our Maemo support as part of Qt4.6 . That was great news for us, Qt for Maemo were no longer supported only by OSS community and Forum Nokia  but also it will be supported Qt Development Frameworks . Now Qt is part of Maemo mainstream but also Maemo is part of Qt mainstream.

Many developers asked me, should I use Qt4.5.3 that is part of Maemo SDk or should I switch Qt4.6 . When the Qt4.6 was released for maemo, Qt4.6 was with "technology preview" tag and Qt4.6 for Maemo was lacking some of key features and it was not yet available at installation package at all. Qt4.6 beta was released 14.10.2009 . We work hard to get first packetized Qt4.6 with all mandatory features implemented as soon as possible. Then, next steps are testing and integrating Qt4.6 by Maemo Devices. When Qt4.6 has passed extensive testings, it will be approved as part of Maemo product and it will replace Qt4.5.3 . Press release states that plan is to have it released 1Q2010.

 

Early Maemo Koffice port and latest port using Maemo Qt UI elements

 

Other question was that why we need to have Qt port for Maemo, why we can't just compile standard Qt X11 version for Maemo? Qt is cross platform and Maemo is based on Linux and X11 . First reason is that Maemo is based on Linux and X11 but it has numerous enhangements to improve it's usability in mobile devices. As example input method that supports mini qwerty keyboard or virtual keyboard. Maemo 5 window manager defines new window types and attributes like Hildon desktop widgets and Stackable Windows that is not supported by desktop X11. Second reason is that Maemo has new several type of user interface elements to improve usability with finger in small form factor mobile device. Qt implements common set of UI elements that exists all mainstream desktop operating systems but that set does not provide optimum user experience in mobile devices. There is more details in my maemo summit presentation.

There was also lot discussion about porting Qt applications for Maemo. Qt is cross platform toolkit and when application is compiled with Maemo Qt, it will have all default Maemo support as example input method and maemo styles are automatically applied. In best case application is usable but usability won't be optimum but application will be usable, least with stylus. In worst case application is not usable at all, as example UI elements does not fit on screen and some of them are unaccessible. To make application usability optimized for mobile device, taking full use af great Maemo 5 user experience and making user interface consistent with all other maemo applications the user interface need to be be re-factored. Good example is KOffice for maemo.To re-factor UI you should keep in your mind how it works in small form factor screen. There is no room for large toolboxes , they eat valuable space from application work area. You may use as example window stack to quickly access toolboxes. You should redesign dialog layouts, big form style dialogs used in desktops does not work at all in small screen. Best way is to use maemo style dialog where content is in finger scrollable list. Other think to consider is usability with finger. Mobile device user prefers using finger and stylus is rarely used at all. All UI elements should be large for finger. Instead normal menus you should use maemo app menus, using scrollbars with finger is not practical, you should use finger scrolling from pane. Maemo Qt port provides necessary UI elements to implement Maemu UI as addition to standard Qt UI elements.

How to start ? At moment i am writting this ( 20.10.2009 ), the packetized Qt4.6 for Maemo is not yet available from repository. Qt4.5.3 was released as beta with Maemo Final SDK. After SDK release, some issues were found, as example missing printing support caused problem with KDE applications. To fix these issues, we have latest snapshot available from http://qt4.garage.maemo.org . These fixes will be integrated to Maemo end of week 44 and then latest qt will be in apps repository.

 

 

After having several questions and face to face discussions in Linux Foundation Collaboration Summit I think that I should tell to wider audience what I had in my mind. I had a presentation titled Animated UI technologies in maeemo 5 "animated_ui_elc_2009.pdf" and I have been talking about Maemo Qt since last summer. Once again I needed to answer questions about what Nokia will do with Gnome.

I remember when I saw first Clutter demo in Guadec 2007, my immediate reaction was that I want this to maemo. We hacked internally Clutter to work in N810 but due legal reasons we were unable to release needed OpenGL-ES drivers for N810.
I also did experimental Qt port for maemo based Qt 3.3.4 but once again it was depending some non public files in these days. Then pieces started to get together.

Summer 2008 we Hired Antonio Aloisio for doing Qt maemo port  and in Maemo Summit  September 2008 Nokia announced that Next generation maemo device will have OpenGL-ES2.0 support. When Maemo 5 Alpha SDK was released in March 2 2009, we released same day Qt 4.5 with OpenGL-ES2.0 support for Maemo. Same Qt 4.5 port will also run in maemo Diablo but without hardware acceleration. Now we were in situation where all pieces were in their places and developers could start developing animated UI for maemo.

We saw quickly results like Kaj Grönholm's http://kgronholm.blogspot.com/2009/04/qt-animation-framework.html animation example or morpheuz animated layouts example http://labs.morpheuz.eng.br/blog/04/04/2009/more-update-about-animated-layouts. The nice thing is that in Kai's example Qt4.5 performs well in N810 even without hardware acceleration.

In my opinion, the future in mobile platforms belongs to the animated UI, it is not just for wow effect, but more importantly, it also it allows to improved usability in small screen mobile devices that are mainly used with finger.

I try strongly emphasize that developers should give up in their mindset about old static 2D widget UI model. Time is to innovate new better ways to build user interfaces. The animated UI toolkits like Clutter or Qt GraphicsView/Kinetic are no longer same thing than old GTK+ and UI design simply has to be done differently than thinking about boxes, what is stored in the box, menu items and the like.  It may be hard to some to give up in their minds their old comfortable GTK+ or Qtopia and learn to think the new way.

The animation toolkits are not the only new thing to learn. We can do scriptable UI where actual user interface look and feel is defined by Javascript and XML files or use embedded browser technology to build user interface.

The legacy GTK+ applications will still run in maemo 5 and most of applications still are made with GTK+ but I just would like to advice developers of new applications to check out the Animated UI technologies and the vast possibilities for usability they offer. I also remind that Gnome  and Qt are still based on same Free desktop foundation layer technologies like Dbus, Gstreamer, Telepathy, Pulse audio etc. They remain same even if we do user interface by new way.

 

---

Comment to about consistency.

The stupid Blog tol did't allow me to comment my own posts :(

Now is time for innovate, time to get ideas to converging consistent UI comes afterwards.

We have realized this issue and we are working on it. But we need to proceed step by step.
We have taken lot of steps to release Fremantle Alpha SDK, Qt 4.5 for Maemo. Also in Qt SW the QT-Kinetic is still in Qt-Labs. Next steps will follow but i think that also developers should prepare their way of thinking to this new technology and not be stuck in old world.     

 

 

---

 

Consistency  continued

I did not say that we are not working for consistent animated UI, I said
that we must proceed step by step, building stone by stone.

I did not say that consistent UI is not required. Don't even
think that Alpha-SDK pre-pre releases of software are ones
that we are going to release as final product.

There is two choices, we can release code and SDK step by step so that
developers can make them familiar with new features or we can keep
everything closed until in some day we have all consistent new UI.

If you like to use animated UI when we have all consistent UI, you simply
can ignore all our alpha SDK's and wait until we have final version out.

I think that majority of developers rather see open development model
from Nokia when we release lot of development versions before final product.

 

The Embedded Linux Conference 2009 is over. Small but technical conference in nice San Francisco Japantown. I will be there also participationg in Linux Foundation Collaborations summit listening to presentations.

In Tuesday evening we had a demo session where I was running maemo on Beagleboad. It looks like Beagleboard is going to be popular hacker toy. I wrote in my Hotel room small demo how to use Qt for animation to make picture carousel, it just took couple of hours and few dozens of lines of code. I run code in both Scratchbox and Beagleboard but it was possible to demonstrate actual compositing window manager feture only in Beagleboard. 

The Animated UI technologies in maeemo 5 Fremantle can be found here animated_ui_elc_2009.pdf OpenGL-ES2.0 looks like being the thing that raises more and more questons among the developers. Even if OpenGL is not new any more, many developers are still using OpenGL 1.0 style API's and now that the OpenGL-ES2.0 forces to use programable shaders, it is big change. Writing animated UI looks also being an area where a lot of new technology development happens. Now is the time for new ideas and lot of paralel development happens at the same area. Then later comes time for convergence .

The Maemo 5 Fremantle presentation is here fremantle_elc_2009.pdf.

Modified 9.4.2009 After demo someones asked source of the simple Qt animation demo i had running in beaglboard. There is source gt4.tgz, feel free to look and try it.  

I have two maemo related presentations in Embedded Linux Conference in San Francisco . Monday 11:00 i have "Animated UI technologies in maemo 5" where i tell more about new UI enabling technologies like OpenGL-ES2.0, Clutter and Qt .Tuesday 2:30 pm i have "Maemo 5 mobileLinux environment with cellular connectivity" where I tell more about what is Maemo 5 .

There is in Tuesday evening demo session. I demonstrate  Beagleboard running maemo Fremantle alpha.

ELC is arranged co-operation with Linux Foundation Collaboration Summit in same location  . ELC is April 6..8 and Collaboration Summit April 8..10 . I will be there around all of the week. There is some well known persons from Maemo community having presentation in Collaboration summit .

If there is maemo developers around and like to talk, feel free and come to talk. May be we can arrange some informal maemo meeting there also .

I will be in San Francisco area untill April 27, i will kep there couple of weeks my vacation .

 

 

 

 

Nokia just announced today alpha version of Maemo 5 ( Fremantle ) SDK. This is the first maemo SDK version with accelerated OpenGL-ES2 graphics support. There are both, kernel drivers and user mode OpenGL-ES2 libraries included.

You can use OpenGL-ES2 directly using C API without need to use GTK+ or Qt. In Qt you can embed OpenGL-ES2 code inside to QGLWidget and then you have all power of Qt and OpenGL-ES2 combined. The easiest way is to use animated graphics libraries like Qt GraphicsView or Clutter that hides all of the OpenGL stuff inside and you have common API regardless what OpenGL version you have.

It is important to know that all OpenGL variants are not similar nor compatible. In Desktop newer OpenGL variants are upward compatible with older variants. OpenGL 2 introduced programmable pipeline, programmable shaders but it still had also traditional OpenGL 1.x API. OpenGL ES 1.0 was made  to be compact, light weight optimized to Mobile devices. Many API's that had duplicated functionality or did not provide optimum performance were removed. For example direct API's glBegin/glVertex/glEnd were removed and parsing vertex arrays with glVertexAttribPointer is the only method. OpenGL-ES2 went even further, now using the programmable pipeline and then write approprite shader program implementing wanted function. On the other hand, you can now implement things that were impossible with OpenGL-ES 1.x. Same thing said in simpler way, simple things became more dificult with OpenGL-ES2.0 but it also has made  new complex things possible.

If you would like to learn more about OpenGL-ES, couple of good  book recommendation is  "Mobile 3D graphics with OpenGL-ES and M3G" and other "OpenGL ES 2.0 programming guide"

Good starting point to start experimenting OpenGL-ES2.0 programming is to download Imagination Technologes OpenGL-ES 2.0 SDK .  SDK is free of charge but requires registration. The SDK contains good set of examples from simple rotating triangle to complicated shader applications. The desktop Linux SDk has OpenGL-ES2.0 wrapper library that implements OpenGL-ES2.0 API over OpenGL-drivers. I have used this SDK in Ubuntu. Compiling basic examples from SDK to maemo arm binaries is straight forward and they will run for example under maemo in Beagleboard. I made just a wrapper debian package to install Imagination SDK OpenGL-ES2.0 emulation library under Frematle SDK x86 Scratchbox target. With this wrapper, you can compile and run same applications under Scratchbox x86 target. The SDK contains as source some other utility libraries needed for more complex examples but I have not yet tried to make maemo arm/x86 packages from them. Even if the SDK is free, I am not yet sure if I could redistribute ready debian packages or just instructions how to pack files from SDK by yourself.

If you would like to know how your application will run in final maemo based mobile products, running application in desktop PC with high performance GPU does not give any usefull information exept that if it do not perform well in desktop, it definetelly won't do it in OMAP3. Omap CPU does not have same floating point power than desktop CPU and also GPU is pover battery life optimized, not maximum performance one.

To run OpenGL-ES2 accelerated graphics in ARM hardware, you need to have TI OPAMP3 based hardware. Untill a Nokia maemo 5 based device is released, you can use the Beagleboard as a development platform. Beagleboard gives a good feeling what will be the aproximate performance in a real device but it is not an exact match. At least in my experience the Beagleboard is not as fast as a well performing OMAP3 device could be. You can find moore about Beagleboard from Maemo Beagleboard garage project and Juha Kallioinen's presentaion in Fosdem 2009 .

 

 

 

 

We announce together with Maemo 5 fremantle SDK alpha Qt4.5 for Fremantle. Qt release is based on Qt4.5 release candidate 1. In this version we have all major functionality of Qt including OpenGL-ES2, Webkit with and Mysql support.We have maemo Hildon compatibility including Hildon menus, Hildon style support, Hildon input menu support. The release includes support for both Arm and x86 targets. The release is still alpha level and wish all comments, suggestions and bug reports welcome.

You can read more from maemo Qt 4 pages  . At this moment, the debian packages are in temporary repository that you get in  use including following line In your /etc/apt/sources.list. It will be in maemo extras-devel as soon than maemo.org is getting repository up.

deb http://qt4.garage.maemo.org/ fremantle extras 

The picture is Arora browser running under scratchbox x86 target. Arora browser is Qt application using Webkit engine and it is build with our Qt release but it is not part of the Qt package. In my other blog entry you can see Qt OpenGL-ES2.0 application in Beagleboard. To run OpenGL-ES2.0 applications you need to have Imagination OpenGL-ES2.0 emulation library installed.

Happy hacking with maemo Qt

 

 

 

I was couple of weeks ago in Gnome Asia conference and there was interesting presentation  about Google Gadgets for Linux  by James Su from Google . The google gadgets are javascript widgets that are loaded to your desktop and then they can run offline. At the moment there is least hundreds or even more Google gadgets that you can download. The Google Gadgets for Linux has GTK+, Qt and browser plugin hosts. I just decides to try how much work is needed to get them running in Internet Tablet. Little work was needed to hack autoconf files because it did not have microb-engine as alternative and then some hacks because maemo has g++ 3.4.4 when Ubuntu has 4.2.3 . After these fixes both Qt and GTK+ host compiled and run in N810 or scratchbox x86 mode.

For some reason GTK hosts did not interoperate correctly with matchbox window manager and made matchbox somehow grazy. The Qt version did not have any of these problems. Current Google gadgets is still somehow mouse centric and needs some modifications to work with touchscreen and stylus, least i have not yet found rught button from my stylus ;)  Little fixes to Qt host to work with stylus and packing stuff in a maemo .deb package and i got my alpha port working.

 It is still early alpha, basic funktionality and maemo install package is there but still lot of work is needed.

I did not yet had time to look GTK+ host more and Gadget add window in Qt also needs to be adapted to tablet display geometry.

I will contribute my patches back to Google Gadgets project and i hope that they could least integrate some non platform-specific fixes like adding microb-engine to confugure scripts to mainstream. I set up google gadgets garage.maemo.org project for maemo port. If is there community interest to participate, please join the project.

 

 

 

Maemo summit 2008 was great success, good "hacker spirit" conference in plce that exactly fits to this, c-base in Berlin. Karoliina made exellent video composition about maemo spirit 2008.

If you like to see video in better quality, check following Vimeo link Maemo Summit 2008 from Karoliina Salminen on Vimeo.

I think that Nokia announced there two most wanted new features to next generation maemo Fremantle, the Cellular HSPA support and OpenGL-ES 2.0 support.

For animated GUI Fremantle will have Clutter toolkit, http://www.clutter-project.org .
Clutter may be best mobile optimized graphics animation toolkit at the moment. Clutter has been designed from beginning to work in mobile devices without need for fast floating point and utilize OpenGL-ES . You can find many nice video examples about clutter from project web site. Clutter is Glib based but it has bindings to many languages including Python, C++ and Vala.

The clutter is not either user interface toolkit or just drawing canvas. Clutter itself does not provide any widgets for UI construction but it has small widget library called Tidy (which is not fully featured toolkit, but rather an example implementation about how to make your own toolkit based on Clutter). Clutter differs from ordinary drawing canvas that it is based on dynamically behaving objects, stage and actors. Actors are display objects that are shown in stage. Actors can be transformed, moved, rotated, scaled or opacity changed. All actor transformations can be controlled by dynamic timelines, paths and they can react to events. For example actor can move via predefined path with speed profile when it receives mouse click event. Actors can contain texture, as example image or even a gstreamer video as a texture. Using these features, it is relativelly easy to make really cool looking animated GUI. 

There was also announced that we will have Qt port for Fremantle in SDK beta release in May-June 2008. Our intention is to have Qt 4.5 version ported for it. Qt graphicsview provides lot of similar functionality than Clutter. Graphicswiew has similar objects, QGraphicScene and QGraphicsItem and QGraphicsItemAnimation and QTimeline for dynamic animation.  Qt software is doing a lot of optimization for Qt 4.5, let's see how it performs in Fremantle. You can read some related stories from

http://labs.trolltech.com/blogs/2008/09/22/sorry-guys/
and http://akademy.kde.org/conference/slides/aKademy2008-HowGraphicsViewWorks.odp

I had a presentation at Maemo Summit about maemo heldon Qt port Qt-Hildon-MaemoSummit08.pdf with Antonio Aloisio and maemo tutorial  "Introduction to maemo hacking". The tutorial material will be here soon.