> On 5 Apr 2017, at 11:24, Mitch Curtis <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
