[Development] Moving QUndoStack and QUndoCommand out of QtWidgets

lars.knoll at nokia.com lars.knoll at nokia.com
Tue Feb 7 12:28:33 CET 2012

On 2/7/12 10:02 AM, "ext Bart Cerneels" <bart.cerneels at kde.org> wrote:

>2012/2/3 Anselmo L. S. Melo <anselmo.melo at openbossa.org>:
>> Hi,
>> On 12/15/2011 07:10 PM, Olivier Goffart wrote:
>>> On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote:
>>>> Hi there,
>>>> I would like to gather your opinion on whether we should move
>>>> QUndoStack and QUndoCommand out of QtWidgets so they could be used
>>>> without requiring this module as an extra dependency.
>> +1
>>>> After a brief investigation, I believe this could done by:
>>>> 1- moving QUndoCommand entirely;
>>>> 2- moving QUndoStack without moving the APIs that rely on or need
>>>> QAction (QAction *createUndoAction() and QAction *createRedoAction());
>>>> 3- creating a new class (QUndoStackAction ??) inside QtWidgets and
>>>> implement the APIs mentioned above there (createUndoAction and
>>>> createRedoAction);
>>>> 4- applying the same logic to QUndoGroup.
>>>> QtWebKit, for instance, would benefit from this immediately, as we aim
>>>> on removing the QtWidgets dependencies.
>>>> Suggestions, comments and any sort of feedback here would be more than
>>>> welcome.
>>> I beleive QAction should also be moved back in QtGui
>> I did some experiments about it yesterday, doing a mix of the two
>>suggestions sent to this thread, i.e., moving QUndo{Command,Stack,Group}
>> and QAction out of QtWidgets. QtGui was built successfully, however,
>>before procced to do the adjustments needed in QtWidgets, I considered
>> important to ask for feedback regarding this task.
>> A question related to the feature freeze: Should I create a new task on
>>JIRA for it, or reopen this old one:
>> https://bugreports.qt-project.org/browse/QTBUG-3415 ?
>> Back to the topic: The current status is: QUndo{Command,Stack,Group}
>>and QAction where moved out of QtWidgets and renamed to temporary (and
>> IMHO bad) names like QGuiUndo{Command,Stack,Group} and QGuiActuion, so
>>the QtWidgets subclasses would maintain the original names, to not
>> introduce additional SiC between Qt4/QtGui->Qt5/QtWidgets. Any
>>suggestions regarding names here?
>> Feedback is appreciated.
>The best case result for me would be to have QAction, stripped of GUI
>specifics, in core and the GUI classes using QAction changed to work
>without the GUI specific functions. If really required a QGuiAction
>offering the old API can be added to QtGui.
>I see the point of keeping the same name for migration but with the
>above I'm wondering how much QtGui using code will really be broken.
>We could also name the stripped class QAbstractAction, but I prefer
>short class names.

Stripping QAction of it's widgets dependencies is going to break way too
much code out there IMO.
Also what do you need QAction for in QtGui? While I agree that we might
over time need something there I do wonder whether QAction is the right
API and abstraction for it.

>I have a use case whereby passing QAction-pointer via
>QAbstractItemModel::data() (actions specific to items and not
>hardcoded in the GUI) the models could potentially be 100% reusable in
>a QML only app [1]. If QAction is not moved then at least I need
>something that can be easily shared between QtGui and QML codebases.

It might be easier (and better in the long term) to create a new class for
this that fits better with the needs of QML and also integrates into


>Development mailing list
>Development at qt-project.org

More information about the Development mailing list