I don't believe it is a good idea to push Direct UI all the way to the application level. The whole point of Qt is it being a library that hides as much as possible of the host platform. So if you introduce a DuiApplication class and assorted other Dui classes will result in 2 things

1) porting existing Qt apps will become harder and more expensive.

2) by the time all systems are multi touch, one would expect Dui to be changed back to Qt. So all apps will have to be ported again.

That's two times work for nothing, with no value being added.

Worse, you cannot advertise to developers that Maemo is a proper Qt platform. It would be if your existing Qt code would compile straight away, and that it would "magically" incorporate multitouch as far as that is possible without application adaption. The only thing I would expect to add code for is those bits of multi-touch that the system cannot abstract away from user code. But that is fine.

Let me give an example. On a multitouch system one can imagine setting a row of checkboxes (representing a set of booleans) by touching two buttons at the same time. All buttons in between will then be turned on. On a single touch system you have to touch them all yourself. At the API level I will see a bitset with some bits on and some bits of. I don't care whether they were set individually or all at the same time. Only if the widget notifies observers of state changes might there be some programming needed, for instance, if the code assumes only a single bit can be turned of or on, I would have to change that (in such a way that the code handles both single bit changes and multiple bit changes in a single state changed event).

AFAICS, existing widgets do not have to be renamed to get them multi-touch enabled. For instance, if I want the default widget that returns a boolean, I don't care if it looks like a slider that's to the left or right, a checkbox that's on or off or a choicelist that's yes or no (this is for those people who remember Series 80). I want the systems standard boolean widget. I don't want to worry at the API level what it looks like, that's the concern of the UI builder.

Only the widgets that make sense only in a multi-touch environment can have a different name, but even then, at some point in the near future multitouch is as common as single touch is today, so having them named differently will be thought of as a bad idea then, so it is a bad idea now.