I don’t consider myself to be a Qt Guru. I might have some ideas and some experience of Qt, but there are plenty of more talented people e.g. in Maemo organization and in developer communities. These things that I write here are just my own thoughts and you can disagree them, but in that case, please leave a comment. Because I have also criticized some parts of the design of the Maemo 6 UI Framework, I think that it’s only fair to provide alternatives or at least proposals how things could be done differently. I don’t want to say that something is implemented or designed bad, if I don’t have justification for the criticism.
After chewing the MVC model stuff couple of days, that I was writing in my previous post, I decided to propose an alternative way to do pretty much the same functionality. The MVC model in Maemo 6 UI framework had the following flaws in my opinion:
- It’s too complex. It requires too many classes in order to implement a widget ( yes, I know there is DuiStylableWidget also)
- It extends the qmake. In my opinion this can be done without code generation also.
- It follows too much the MVC ideology. In my opinion there is no need for a model class. These can be ordinary class members.
- Setting a size for a widget is bit weird. I’m not sure should I set the size for a controller or for a view
Proposal for MVC
Here is my proposal in simplified UML:
Addition 15 minutes after I published this. I just realized that this model sucks in that sense, that there is no reason why EnumeView class should inherit the QGraphicsWidget. So basically that inheritance could be removed.
Few words about this new model. The idea is that each widget must inherit EnumeWidget (Enume is a prefix for my free time coding so never mind that, it’s just a name). Each EnumeWidget has at least one default view, which is set automatically when calling EnumeWidget’s constructor. By default the view does nothing. It is up to the user of this MVC model if she wants to provide a custom view for her widget or not. The other option is just to re-implement the EnumeWidget::paint(QPainter*) method in a subclass and do all the drawing there.
In this model, it is up to the user if she wants to create “MyWidgetView” or not, it’s not compulsory thing to do. If a custom view is implemented, then it’s possible to re-implement the drawing methods for background, contents or foreground. This is exactly the same way as it’s done in Maemo 6 UI Framework.
The EnumeWidget is meant to act as a controller so it’s basically pretty much same as DuiWidgetController. One big issue here is that how the size is set for the EnumeWidget? I solved this issue so that it doesn’t matter if you set the size for the EnumeWidget or for the View because in every case you will set the size for the view. This is the one reason why each EnumeWidget has a view. And when EnumeWidget::sizeHint(..) is called it returns the size of the view. This way the size is always correct and EnumeWidgets can be placed to the QGraphicsLayouts also.
Because EnumeWidget is a controller, it handles all the events and custom “events” like orientation and style changes. The style changes could be handled by the view also, but I rather keep that in controller side. I didn’t want to make here anything special related on styles, because the actual implementation how the style settings are retrieved from what ever source is a detail that doesn’t belong here. You can do it e.g. via singleton class, which identifies the style attributes via object name.
What about the model then? The model is the data that is stored in EnumeWidget’s instance variables. That’s it. I don’t see there any reason why the model should be more complex than that. Please let me know if there is a reason for that?
Proposal in Action
In this video I show the cases of for what model can be used for. There are two different type of buttons: one which have a view and a simpler one which doesn’t have a view. The buttons with a view, change their sizes when orientation changes and the buttons without a view don’t do anything else than react on the mouse presses.
The source code is available from Gitorious: git clone git://gitorious.org/enume/enume.git
The demo code is in widgets and mvc-demo directories. I know the code is not perfect, but it’s just a Proof-of-Consept stuff, oh yes and there is also this PannableView code which “not so perfect” and is currently under work.
Comments