[Interest] Is QML the right tool for my job ?

Till Oliver Knoll till.oliver.knoll at gmail.com
Thu Nov 27 14:13:24 CET 2014


> Am 27.11.2014 um 11:46 schrieb Jean-Michaƫl Celerier <jeanmichael.celerier at gmail.com>:
> 
> ...
> 
> I also read somewhere that undo-redo and that kind of stuff did not always play well with QML, but we have already a full MVP + Command pattern implemented
> 
I have never used QML in practise, so I cannot really add anything here with respect to that, but whoever wrote that "undo & redo does not play well with QML" IMHO did not understand the MVC pattern (or MVP) and the undo/redo command pattern ;)

Undo/Redo acts on the Model, and the only responsibility of the View (here: e.g. implemented with QML/QtQuick) is to react accordingly.

There is (should!) no direct interaction between a Undo/Redo pattern with the View. So I don't see how a View implemented with QML/QtQuick should be a drawback in that respect.

It is true that certain QWidget-based UI elements such as QTextEdit have their own ("local") undo/redo stack - because they also incorporate also their own ("local") Model (the text being edited). But that is "for convenience" only at best, and should probably not be used at all if you want to use an application-wide undo/redo stack (and the text being edited by a QTextEdit widget should eventually be copied into a "proper" Model data structure, on which the undo/redo operate).

I could imagine that "QML elements" which come "out of the box" with Qt do not support at all such a "local convenience undo/redo stack" (because they are supposed to represent the Model only), and maybe that might have led people to think that "QML is not suitable for undo/redo"?

Don't let statements such as those put you off QML ;)

Cheers,
  Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20141127/0db27ac4/attachment.html>


More information about the Interest mailing list