[Development] Moving Qt's undo framework out of Qt Widgets
Shawn Rutledge
Shawn.Rutledge at qt.io
Wed Apr 5 12:34:15 CEST 2017
> On 5 Apr 2017, at 11:24, Mitch Curtis <mitch.curtis at qt.io> wrote:
>
> I'd like to remove the undo framework's dependency on widgets. There's a bug report for this here:
>
> https://bugreports.qt.io/browse/QTBUG-40040
>
> My plan is mentioned in the commit message of the following change:
>
> https://codereview.qt-project.org/#/c/190704/
>
> To summarise:
>
> - Introduce QGuiUndo* classes that don't have any QAction-related API (which is the only thing tying the framework to widgets)
I keep wishing that QAction wasn’t tied to widgets either, though. Could we fix that in Qt 6? I think it would remove obstacles in quite a few places...
> - Make the existing QUndo* classes derive from the respective Qt Gui classes
>
> This would allow existing code that relies on the QAction API (or otherwise uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. Qt Quick applications to use the undo framework without relying on widgets.
>
> This is a change for Qt 6, seeing as we cannot "[for existing classes] change the class hierachy in any way (add, remove, or reorder base classes)."
>
> https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts
>
> If people are OK with having duplicated code until Qt 6 (it's code that's rarely touched anyway), we could also introduce the QGuiUndo* classes in the next applicable minor version.
>
> Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do with graphics". While he phrased it in a pretty ridiculous (the majority of applications using undo/redo are graphical user interfaces) and familiarly arrogant way, I do agree that non-GUI applications could benefit from this.
>
> So, should this get its own module, and if so, can widgets depend on it?
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
More information about the Development
mailing list