The future continued

Published Friday April 9th, 2010
16 Comments on The future continued
Posted in Graphics Items, Qt, Qt Quick

Proof Of Life

As mentioned in previous blog posts, we are currently playing around with ideas for a new widget architecture. While I was in Brazil, I spent some time working with guys at INdT in Recife. We decided to put together a proof-of-concept demo.


QML application using styled components.

Hey Good Lookin’

The idea behind the project is to take a different approach to UI components and from what we have done in the past.
In Qt today the look-and-feel of a widget is to a large degree implemented in the widget itself, often intertwined with the logic. Styling of widgets is done by forwarding painting calls to QStyle and by requesting hints from the style for certain behavior or property values.

As I wrote in I can haz teh future, plz, we want to separate the UI component data-and-logic from the look-and-feel. This allows us to save the UX designer from having to deal with the messy, complicated and error-prone parts, while at the same time saving the developers from additional pain when said designer changes his or her mind. Win-win. 🙂

In my presentation at the Bossa’10 Conference I referred to the component’s data-and-logic part as “controls”, but after a reconsidering, I now refer to them as “models” (as per the MVC design pattern). The component models are implemented as sub-classes of QObject and export their values through properties.

Slider Component
Separating look-and-feel from data-and-logic.

We implement the look-and-feel part of the UI components using QML since this is what it does best.
As part of the proof-of-concept we have also implemented a styling system. The idea is that it builds the component by populating it with a scene-graph consisting of primitives. This gives the style full freedom to decide how the widgets will look and behave.

I Can Haz?

You can find the repository here. We still keep our discussions on the widgets-ng irc channel and mailing-list. Feel free to join us in our quest for UI snazzyness and general well-being! 😉

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Graphics Items, Qt, Qt Quick

16 comments

Alex says:

The style-related stuff should probably be discussed with the GTK+ team. I would love to see the distinction between a Qt theme and a GTK+ theme go away.

Benjamin says:

Please don’t put too many layers/too much complexity onto Widgets.

Java’s swing use model-view-controller for any widgets, and it is a huge pain in the ass to use. Having a ButtonModel, 6 listeners, and a JButton to implement a push button is just silly.

JarJarThomas says:

I can only assist Benjamin.

Having a ui system that is fully in the hands of the artists is one thing, adding extra development effort to use this … makes it just useless.
I like to have good looking ui’s. And if there is a way to have a ui completeley separated from sourcecode … perfekt.
BUT if this is only usable in special circumstances AND only with so much overhead on both sides that it takes to much time … it is just an epic fail.

I tried working with qml … and altough it is a nice system to play with … i really can’t see any real usage in it know because it is to limited and takes to much effort. I do not have simple ui’s like a website with three elements that can fade in/out.

I have eg a complicated ui with about 160 different controls visible on different pages, they need to react separately from each other.
Using states for transformation for the whole ui is just ridiculous, adding for each control models makes it more pain in the ass than you can imagine.
The only way i see how to use qml would be to give the qml for each widget to an designer just telling him “hey … here you have the widget, design it to show these values, modify these values and finished”.
Then i need a higher level syntax to allow him to place and control the widgets together to groups
And another higher level syntax to allow different widget groups to work together.

One lowlevel system as qml is just not usable. And if it takes me additional time to implement models with the same complexity as the current mvc system … i rather would quit the job.

Denis says:

Qt is great for its relative simplicity in terms of widgets usage. E.g., I still do not use QtDesigner placing all widgets in c++ code in rather complex applications with dozens of forms and custom UI styles. Please, do not add excessive complexity for the sake of new developers have less troubles starting with Qt.

After all designers will always find their tricky way to spoil developers’ lives ;).

Philippe says:

I second the last posts, remain pragmatic! Personally I am much more eager to find in 4.7 an equivalence to QGraphicsAnchorLayout for QWidgets, than any QML stuff.

Philippe says:

BTW, the idea that designers would do better UIs than programmers… yes (well, maybe), but what about the numerous small companies and independent developers that simply can’t afford the services of a designer?

mbm says:

@JarJarThomas: Don’t worry. 🙂 Although the idea of the component models was the focus of the blog-post, we want to provide more than that. The idea is that the UI component and style implementation is flexible enough that you _can_ radically change the component look & feel if you want. Also note that the architecture is not necessarily limited to using QML for the look & feel. It depends entirely on the style implementation.

Andrew Ford says:

This is really to the heart of MVC design. As a developer, I hate creating UIs because I know that I suck at it. Life is so much easier when I can gather the data and pass it off to the UI guys and let them do their thing. QML really lets the developers focus on developing and the designers focus on designing. This is really good stuff!

zuck says:

In my opinion this is a very good design choice 🙂

garfield says:

+1 On the skeptics side.

The reason is simple: To make complex stuff like user interaction and/or look and feel “easy” – you have to abstract. And abstraction is double edged sword. You (the developer) have to do “some work” to make someone else’s (the designer’s) job easier/possible. And you pay this overhead in hope it is worth it. But does it?

The problem is – these solutions do not scale. None of them (Flash, Flex Wpf etc).
Yes, its cool for presentation demos to wow the monkeys in the hall. Its easy to mock up a simple (dummy) UI, but the moment you step into the real projects, you realize you have to play the prise. (Before that the price was paid by the framework vendor to hook you up).
Now, the prise *might* be worth it, but one has that bitter taste in the mouth he/she is doing extra work to enable scenarios of no real value for the end user… they only “ease the development process”.

I’d say there’s pros and cons. Let me summarize why.

From my perspective you’ve got two kind of UI projects:

– Traditional apps (Word, Steam, Firefox etc).
– Multimedia apps (Games, Cellphone apps, Fancy media center to impress your girlfriend).

Let’s face it guys, we’re in 2010 we need to do both and sometimes combine them. But please remember that traditional apps are far from being obsolete they have a different purpose.

I don’t see how QML will help me to produce better “Traditional apps”. I think the user hates fancy interfaces when it blows up usability.
The user does not want to be surprised, he wants the good old stuff. That’s the first point.

But there’s more, I don’t think designers are good at traditional apps. In most cases they can’t figure out every ins and outs. So they end up doing messy choices damaging user-friendliness.
Bottom line is: in the traditional app world a good UI coder should learn to “design it”. Nobody will do that for him.

As for Multimedia apps there is no doubt that there is room for QML and designers (you guys can’t sit back and drink a Pina Colada forever). But remember, in that scenario we get rid of finesse to get back “Wow effects” and style.

In my opinion the future is not about a single best way, it’s about diversity.

There is a last point. The hybrid app, an application that mixes both “Multimedia” and “Traditional” components. But I have no room to talk about this here.

I’m working in the gaming industry (poor me) and we happen to use both of these approaches, so I’ll try to post a few more insights in http://www.warriorlabs.net feel free to tell what you think.

Benjamin Arnaud.

mbm says:

@Benjamin Arnaud: I wholeheartedly agree! There will be a need for the traditional widgets in the foreseeable future. We could go ahead with two separate implementations or we could look for a way to share code and by doing so also improve the existing widgets. The component models allows us to do this. We can use the same “backend” for UI component used by QML and for our QWidget-based widgets (where it makes sense).

Dom says:

“Traditional apps” can take advantage of QtQuick. QML helps enforce separating things better in such projects. Since graphical user interface look and behavior is made in a language more specialized for that (QML), it will be less tempting to add some lines of code here and then that depend onto QtGui at places where it should not. And avoiding to do that naturally brings us to the paradigm shift someone was talking about some weeks ago on this blog. As long as Nokia does not only focus on cellphones apps, I only see positive points in using QtQuick for every kind of applications.

Matt Gilg says:

Ok, so I feel compelled to comment on a couple of things.

@JarJarThomas
“I tried working with qml … and altough it is a nice system to play with … i really can’t see any real usage in it know because it is to limited and takes to much effort.”

Too much effort…to read the docs? 🙂 QML is worth learning, period. I write control software for embedded devices, and I’ve saved countless hours by using the technology. QML allows custom types, has Qt’s excellent data models, and fantastic signals/slots integration. I’m confident in saying that there is nothing that I can’t do with QML that I can with standard components. Every bit of the learning curve was worth it, because it always gives me the upper-hand in ui design.

@garfield
“The problem is – these solutions do not scale. None of them (Flash, Flex Wpf etc).”

Sure they do. Thousands of users launching a flex app that modifies data stored in a centralized database isn’t considered scalable?

@garfield
“The reason is simple: To make complex stuff like user interaction and/or look and feel “easy” – you have to abstract. And abstraction is double edged sword. You (the developer) have to do “some work” to make someone else’s (the designer’s) job easier/possible. And you pay this overhead in hope it is worth it. But does it?”

Well-designed software takes the user and his/her needs into account first. Plus, ui design with QML is far more efficient than typical design, forces the model/view/controller paradigm, and is easier to maintain in the long-run. You (the developer) have to do work to make someone (the end-user — not the coworker or designer’s) job easier.

@Benjamin Arnaud
“I don’t see how QML will help me to produce better “Traditional apps”. I think the user hates fancy interfaces when it blows up usability.”

QML doesn’t blow up usability, and it *can* help you to produce better “Traditional apps” because it forces good design sense. (Nothing like a dose of upfront perceived ‘inflexibility’ to make developers organize their tasks at hand and focus on the data that the program is actually modifying/controlling.) In many ways, QML can help keep developers from “butchering” an interface design.

@Dom
“Since graphical user interface look and behavior is made in a language more specialized for that (QML), it will be less tempting to add some lines of code here and then that depend onto QtGui at places where it should not.”

Exactly, nail on the head. QML makes it tougher to add a short-term “Kludge” to the interface, another reason that QML lends itself to great design.

@Dom
“I only see positive points in using QtQuick for every kind of applications.”

Completely agree. Folks who think otherwise should do a bit more investigation. 😉

Overall, the Qt Declarative library allows users to do more with less. Sure there is a learning curve, but there always is when you experiment with implementing something new. Look beyond the limitations, and spend a little time with the technology, and not only will you write better applications, you will save yourself boatloads of time.

-M

NuShrike says:

I think you guys would get more results attacking it from the angle of template policy classes. For instance, you could make QAbstractButton a policy whose behavior is shared between QPushButton or anything else such as QGraphicsWidget.

template
class AbstractButtonT : public BASE
{
public:
void setText(const QString &text);
};

class GWPushButton : public AbstractButtonT
{

protected:
virtual void paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget);
};

There, now you’ve separated behavior from UI. Easy sharing, collapses into smaller code than the MFC-like bloat Qt has now. Currently, GraphicsView is really difficult to customize upon for me because none of the useful policies from QWidget can be bridged to QGraphicsWidget due to the current DAG inheritance.

Not sure how similar this idea is to Java’s Swing nor the implications for LGPL if a lot of widget code gets inlined into an app due to templates, but it would really push the framework forward, imo.

I also would really like to see UI improvement shrink its memory footprint. In WM6.5.x, just a simple QMainWindow with a QGraphicsView in it takes up to 1MB of ram (with cleanlooks style) when the equivalent written in Windows Template Library would take a magnitude or 2 less.

NuShrike says:

Seems the good stuff got blanked out. Should be (change [ ] to angle brackets):

template [typename BASE, typename IMPL]
class AbstractButtonT : public BASE

class GWPushButton : public AbstractButtonT[QGraphicsWidget, GWPushButton]

Commenting closed.

Get started today with Qt Download now