Zchydem's Blog

I guess, I can say that I have some experience of Qt. I started to use it 2001 in Åbo Akademi’s research project, but we were using PyQt at that time. Later I started to to use C++ version of Qt and now I have used Qt over 4 years in my daily job. I have mostly developed Qt applications and frameworks  in other  than standard PC platform, like for PowerPC and Arm. I also started to use Qt’s Graphics View when it was first released. So I believe that I do have  little competence to do a review for the Maemo 6 UI Framework.

I needed to divide this review to several articles, because the Maemo 6 UI Framework is really large. In the part I do a small review without going too deep and I will also tell you how to create a simple application running on top of Maemo 6 UI Framework.

Btw, good reading for C++ portability can be found here. If you are more interested in about doing little research about Maemo 6 UI Framework, you can glone the sources from gitorious. I hope, that you will leave a comment if you disagree something in this article. I also assume that the reader have some kind of understanding of Qt, so I don’t explain everything. Instead I will put a link to Qt documentation when ever it’s possible.

To make things more clear this article is not about the Maemo 6 Homescreen, but the UI Framework. I will write another article about the Homescreen later. Another thing to remember while reading this article is that we are speaking of “Techical Review”, not a release candidate, not a beta or not an alpha, so things will probably change a lot, hopefully improve. Let’s begin this review with some basic “grep” and “sloccount” tests.

SLOCCOUNT

At first I decided to run couple simple tests to find out if there are some basic rule-breaks that people usually do when they start to implement software for embedded environments (I know that Maemo devices are not exactly embedded devices). So to get some kind of idea how large the framework is I ran sloccount. Below is the summary:

• Totals grouped by language (dominant language first):
• cpp:          97221 (97.90%)
• perl:           897 (0.90%)
• ansic:          563 (0.57%)
• sh:             259 (0.26%)
• python:         220 (0.22%)
• ruby:           138 (0.14%)
• sed:              7 (0.01%)

As you can see from the summary, the Maemo 6 UI Framework contains quite amount of code. There are almost 100 000 lines of code (real code, not comments and empty lines are counted on it) at the moment of writing this. I also want to state that my intension here is not to find only defects from the Maemo 6 UI Framework, but also to check the general state of the code. I assume, that I will do also a positive findings. At least I hope so.

RTTI Usage

Next I ran such a simple tool called “grep” to find out if they use RTTI which usually is not a recommended way to do casting in C++ in embedded environments. Qt provides nice QMetaObject system which introduces better option for dynamic_cast<T>() via Qt’s meta object system. For basic QObject casting there is a qobject_cast<T>() and for Graphics Items there is qgraphicsitem_cast<T>(). And if you’re not able to use these you can use static_cast<T>() which is a compile time check and should not cause any problems. I guess the TT guys have introduced their own casting system in vain. I found that there are some classes under widgets directory that really use dynamic_cast<T>(). See the list below. The number after the file name tells how many times dynamic_cast<T>() is used in that file.

• ./animation/duibasiclayoutanimation.cpp:6
• ./core/duiapplication.cpp:1
• ./core/duiinputcontext.cpp:2
• ./declsettings/duideclarativesettingsbinary.cpp:2
• ./declsettings/duideclarativesettingsfactory.cpp:1
• ./declsettings/duideclarativesettingsitemfactory.cpp:1
• ./layout/duiabstractlayoutpolicy.cpp:1
• ./layout/duibasiclayoutanimator.cpp:3
• ./layout/duidynamicgridlayoutpolicy.cpp:1
• ./layout/duidynamicgridlayoutpolicy_p.cpp:1
• ./layout/duilayout.cpp:3
• ./layout/duilayout.h:2
• ./layout/duilayout_p.cpp:2
• ./mashup/mashup/duiapplethandle.cpp:8
• ./mashup/mashup/duiappletinventory.cpp:3
• ./mashup/mashup/duimashupcanvasview.cpp:6
• ./scene/duiscene.cpp:3
• ./scene/duiscenemanager.cpp:6
• ./scene/duiscenewindowanimator.cpp:1
• ./theme/duiimageloader.cpp:4
• ./widgets/core/duiwidgetview.cpp:2
• ./widgets/duidialog.cpp:1
• ./widgets/duipannablewidget.cpp:1
• ./widgets/duiviewcreator.h:1
• ./widgets/duiwidgetfactoryplugins.cpp:1
• ./widgets/duiwidgetrecycler.h:1
• ./widgets/views/duigridview.cpp:3
• ./widgets/views/duilistview.cpp:5
• ./widgets/views/duimenuobjectview.cpp:1
• ./widgets/views/duimenuview.cpp:1
• ./widgets/views/duipopuplistview.cpp:1
• ./widgets/views/duislidercontinuousview.cpp:1
• ./widgets/views/duitoolbarview.cpp:2
• ./duiappletrunner/duiappletrunner.cpp:10

NORMALIZING SIGNAL AND SLOT SIGNATURE

Next thing I wanted to test how well the Maemo 6 UI developers know how Qt works internally. Not many people know that Qt normalizes the signal and slot signature before they are used. What this means in practice? If you write in your code a line:

connect(sender, SIGNAL(mySignal( const QString & )), receiver, SLOT(mySlot( const QString &) ));

Qt will remove all the whitespaces, const keywords and reference sign & so that you it will end up to the form:

connect(sender, SIGNAL(mySignal(QString)), receiver, SLOT(mySlot(QString)));

This may sound not so big deal, but you can also do these connections in a loop in a run time so there might be cases where this can effect in some way. After running grep against the code base I found quite a many cases where signal and slot signatures weren’t normalized. I don’t put the results here to save some space, but this gave me a picture that there are quite many people that don’t know so deeply how Qt works. This is of course understandable because UI Framework requires definitely many developers and they all can’t be Qt Gurus.

DIVING INTO A CODE

I’m not going to to go through all the code, but some essential classes so that you should be able to create a simple application for Maemo 6 using their fancy framework after reading this. Good thing about the code quality is that they use Qt’s macros quite well. For example they use Q_Q(ClassName) macro to get access to private classes via “d” pointer. They also follow Qt convention on naming functions like they don’t use getFoo(), but they use setFoo(X) and X foo() const for setters and getters. On the other hand they don’t use Q_EMIT, Q_SLOTS and Q_SIGNAL macros to avoid conflicts e.g. if using Boost libraries. So this sort of gives me a feeling that do they really know what they are doing and what they should use in Qt? I’m bit confused here now…

CREATING A MAEMO 6 UI APPLICATION

Toman Junnonen gave an presentation in Maemo Summit 2009 where he explained that everything in the framework is based on Graphics View. I decided to take a look how the application is built on top of the framework. I generated the doxygen documentation from the sources to make easier to browse the documentation. Btw, if you create the doxygen documentation this ui framework has “working title” there from where the “Dui”-prefix seems to come:) I don’t want to tell it here, but generate the doxygen documentation if you want to see.

To create a simple application write:

      #include <DuiApplication>
      #include <DuiApplicationWindow>
      #include <DuiApplicationPage>
      #include <DuiButton>

      int main(int argc, char *argv[]){
          DuiApplication application(argc, argv);
          DuiApplicationWindow window;
          window.show();
          DuiApplicationPage page;
          new DuiButton("Hello", page.centralWidget());
          page.appear();
          return a.exec();
       }

Remember to add the following line: CONFIG += dui in your pro-file. You can check the demos directory to see more examples. So what happens with the code? You create an DuiApplication object, which inherits QApplication providing the basic event handling and etc. Then you create the DuiApplicationWindow which inherits DuiWindow, which inherits QGraphicsView. So basically this piece of code creates QGraphicsView and shows it.

DuiWindow actually uses DuiSceneManager singleton class to create the QGraphicsScene where all the QGraphicsItems or QGraphicsWidgets or QGraphicsObjects based items can be placed. There seem to have some code that handles the orientation changes at least in the beginning when the application is started. The DuiApplicationWindow handles a navigation toolbar and view menu also. At this point the application basically have an empty window.

To add some content to the application we must create there an DuiApplicationPage object. DuiApplicationPage provides a framework for building an application’s user interface. By default the page creates a pannable area where a user can place his component by using centralWidget() or setCentralWidget(DuiWidget *). In this example the central widget is passed as a parent to the DuiButton object. In the end the DuiApplicationPage::appear() is called to make page appear with animation. Calling appearNow() makes the page appear without an animation. In the end the Qt application event loop is started. So this is the basic stuff that you need in order to create a simple Maemo 6 Ui Framework.

NEXT ARTICLE

This was all for this time. In the part two I will tell you about the MVC model in Maemo 6 UI Framework. Thanks for reading:) Part II is available here.

Tags: Maemo, Maemo 6 UI Framework, Nokia, QGraphicsView, Qt, Review, RTTI

This entry was posted on Thursday, November 12th, 2009 at 7:11 pm and is filed under Maemo. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.