QML vs QGraphicsView - choosing the right level of abstraction

fbreuer

Hello!

For what types of projects is QML the right level of abstraction and when is QGraphicsView more suitable? All of the example QML applications I have seen are small "iPhone-style apps", viewers or from-like database frontends. Is QML suitable for applications that deal with editing documents, like a word processor, for example?

Two aspects interest me in particular:

QGraphicsView is advertised as being able to cope with millions of items. Is the same true of QML? In the word-processor example, would it be practical to represent every paragraph of text by a separate QML item? Would this approach scale to a 100 page novel? Or does the overhead imposed by QML over QGraphicsView make this impractical?
If the number of items in a QDeclarativeView changes dynamically (as in the paragraphs in a novel example), is it still practical to manage these changes from QML? Or would the traditional C++ approach be the tool of choice? Also, I find the tools for describing abstract state machines in Qt very appealing, but these seem to be focused on small finite state machines (or at most states parameterized by scalar variables). I take it that handling an unbounded list of paragraphs, each with its own internal state, impractical, especially if paragraphs might be nested?

Please let me know your thoughts on the matter!

Thanks,
Felix

dangelog

No. Go for ordinary widgets. The features of QML/QGV (and their overhead) aren't much of help in case of a word processor.

fbreuer

Hi peppe, thanks for your reply. Even though I am dealing with a word-processor-like application, I will have to do a lot of custom drawing. I investigated the use of ordinary widgets with custom paint methods, which turned out to be too slow. I will require the optimizations that only a proper canvas can afford. This lead me to QGV.

So I am interested in the overhead/performance differences between QML on the one hand and QGV on the other hand. How much impact do the niceties provided by the JavaScript virtual machine have? On the other hand, if QML is ported to the QML Scene Graph backend in the future, QML may actually become faster than QGV in certain cases. The question is which way the balance will tilt, if large editable documents with thousands of items have to be rendered.

Nonetheless, I think you are right, peppe, and QML is not the right tool for the job.

2beers

Well I start to slowly change some of my applications to QML. For the moment only small objects, so the speed doesn't slow. Once the QML scene graph is done , I will probably move almost all the interface to QML. At least for me it works because I want to add more kinky-animated look to my applications. Depends what do you want.