Zchydem's Blog

This article continues the series of Maemo 6 UI Framework review. In the first article I did couple simple metrics measurement using basic unix/linux tools. I also showed how to create a simple Maemo 6 UI application. In this article I want to introduce a consept which is heavily used in the framework. It’s called MVC model i.e. Model-View-Controller. For those who are not familiar with this consept, just google it and you will find thousands of refers to it.

In general the MVC model works in the following way:

• Model – contains data
• View – Visualizes Model’s data. Same model can also have arbitrary amount of views e.g. one view presents data in table and the other view visualizes it in a list or graph etc.
• Controller – handles e.g. events such as mouse clicks, keyboards events and so on

Qt has the MVC consept (at least) in two different ways. Qt introduces the Qt’s Model View Framework, but  it has nothing to do with Maemo 6 UI Framework’s MVC model. Btw, it’s worth to checkout Qt’s Model View framework and especially how models work in Qt, because you can use the same models in Maemo 6 UI Framework also. For example the DuiGrid or DuiList take QAbstractItemModel as a model and provides a view for it.

Then Qt also provides the MVC, but in implicit form. So basically each QWidget or QGraphicsWidget based objects can handle events (controller), drawing (view) and the data (members) i.e. they  combine MVC model into a one class. This is not a case when dealing the Maemo 6 UI Framework. There you need to have explicitly a class for each part i.e. class for model, class for view and a class for a controller. Sounds complicated, yes I know. This is getting bit more complicated because  you need to have a class for style also. So you need four classes to implement a widget.

I believe that a picture will tell you more than words so here is a simplified UML class diagram of MVC model in Maemo 6 UI Framework. I know it’s not a perfect, but it should give you a picture how classes are related. Note that I don’t have time to go through everything so I explain here only the main things.

DuiWidget & DuiWidgetController

DuiWidgetController is an access point to the widget’s user. For example when you create an instance of DuiButton, you will create a controller object. DuiWidgetController extends the DuiWidget class which only provides some orientation changes related stuff and  custom event handling. I don’t know why these things are not implemented in DuiWidgetController directly which would sound more logical to me, but this is just a review and it’s purpose is to raise questions also. In order to make styling work, each object must have object name i.e. it sets it by using QObject::setObjectName(..) method. DuiWidgetController handles setting the view and the model instances when it’s being created.

DuiWidgetView

The view for the controller must be inherited from the DuiWidgetView. The DuiWidgetView usually implements drawing methods. It will be notified if a style or model changes so that it can update it’s visual appearance. View must also defined a sizeHint(..) which  is used e.g. when the widget is put into a layout.

DuiWidgetModel

A model is just a data container. Basically what application developer must do is create a header which contains the class definition and macros for defined the model properties. The properties are quite similar how Qt defines those (using macros) but Maemo 6 UI Framework will extend them bit. Below is example of model declaration:

  #ifndef DUIBUTTONMODEL_H
 #define DUIBUTTONMODEL_H

#include <duiwidgetmodel.h>

class DUI_EXPORT ButtonModel : public DuiWidgetModel
{
     Q_OBJECT
     DUI_MODEL_INTERNAL(ButtonModel)
 private:
     DUI_MODEL_PROPERTY(QString, text, Text, true, QString())
     DUI_MODEL_PROPERTY(bool, down, Down, true, false)
};

 #endif

DuiWidgetStyle

Each widget in Maemo 6 UI Framework have a style. The style can be something like a font for the button text, border colors, text alignment etc. Styling can be changed on the fly and I believe one reason for this is the portability and theming. With the portability I mean that there will probably be different devices that will use Maemo 6 UI Framework (later) and they may have different kind of visual appearance for same objects. This is just a speculation, but I guess they try to design a platform for more than just one device. When a style changes the changed style values can be stored to the model. Below is an example how to define a style:

#ifndef DUIBUTTONSTYLE_H
#define DUIBUTTONSTYLE_H

#include <QColor>
#include <duibuttonstyle.h>

 class DUI_EXPORT ButtonStyle:public DuiButtonStyle
{
     Q_OBJECT
     DUI_STYLE_INTERNAL(ButtonStyle)

     DUI_STYLE_ATTRIBUTE(QColor, glowColor,GlowColor)
     DUI_STYLE_ATTRIBUTE(int,glowDuration,GlowDuration)
};

class DUI_EXPORT ButtonStyleContainer:public DuiButtonStyleContainer
{
    DUI_STYLE_CONTAINER_INTERNAL(DuiButtonIconStyle)
};

 #endif

How to Combine All this?

You may wonder how everything is put together then? For example the model and the style classes are only headers. Where do they get their  implementation? The answer is that the implementation will be generated. The Maemo 6 Ui Framework extends Qt’s qmake so that you define the model and style headers as shown previously and the code will be generated for those.

Questions and Thoughts about All This?

This Maemo 6 UI Framework MVC implementation is definetly not the simplest one that I have seen during my career. It raises several questions:

1)  I don’t fully understand is also why DuiWidgetController passes mouse events to the view instance when using the MVC model? In my understanding the MVC model should work in a way that controller receives events, handles them and modifies the model, which may inform the view about the changes in order to make the view update. I also know that it’s much more practical to do some mouse event reactions on the view side instead of on the controller side e.g. you draw something when user taps the widget. But my point here is that now you can make a widget where both controller and view handles the mouse events.

2) Another thing that I don’t fully understand is that why both of the controller and the view have sizeHint(..) method? Isn’t the view the only one that should define the size for the widget, because it defines the look of the widget? Should the controller know anything about the size? Is it so that the controller’s size is the size of the view? Things get too messy at this point too….

3) To create a simple widget it requires (too) many classes to implement everything what is needed. In the end this same thing could have been done using one class or if there is a requirement to be able to change the view, the same result would have been gained by implementing one class for Controller+Model and one class for View. Wouldn’t this be much easier and that’s how it’s already done in Qt.

Wait! There is a simpler way to do all this

There is a class called DuiStylableWidget, which is a simplified way to create stylable widgets. Basically you create a subclass of the DuiStylableWidget, implement paint() method for it and also you need to provide the style class in the same way than in MVC. I guess this approach will be more popular when developing 3rd party software on top of the Maemo 6 UI Framework.

Review Result…

It looks like that there is a nice idea behind the MVC implementation, but it seems to be little bit “over engineered”. With this I mean that in the end all will fall back to the QGraphicsWidget.

QGraphicsWidget originally receives Qt events (Controller), it is the one that gets the paint event (View)  and forwards it to the DuiWidgetView instance and if that QGraphicsWidget would have any class members (attributes) it would also act as a model. I think that it’s quite easy  to create stylable widgets by introducing the subclass of the QGraphicsWidget wich have e.g. abstract method called: styleChanged() = 0. This method would be called by the StyleManager or something like that which monitors style updates. Then all the widgets who want to have a style may provide an implementation for that styleChanged() method.

I’m not sure if this proposed approach would work, but I am a simple man who likes to think simple and who likes to do things in a simple way. IMHO, is that there are too many phase for creating a simple stuff. It should not include anything which requires code generation, it should not extend qmake anymore and it should not require 4 classes to create a one widget (Actually there is more than 4 classes).

That’s all for now. There will be part III and it subject will probably be about the layouts and orientation, but I need to do some research before that.

Addition: The part III is here.

Tags: Maemo, Maemo 6 UI Framework, MVC, Qt

This entry was posted on Saturday, November 14th, 2009 at 8:55 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.