> -----Original Message----- > From: Konstantin Tokarev [mailto:[email protected]] > Sent: Wednesday, 5 April 2017 11:29 AM > To: Mitch Curtis <[email protected]>; [email protected] > Subject: Re: [Development] Moving Qt's undo framework out of Qt Widgets > > > > 05.04.2017, 12:24, "Mitch Curtis" <[email protected]>: > > 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) > > - Make the existing QUndo* classes derive from the respective Qt Gui > classes > > Out of curiosity, why does this code have to be in QtGui? Looks pretty-much > GUI-independent.
It doesn't, it just seemed like a reasonable option to me; it's in the same repo and it's mostly used by GUI applications. The same could be said about QValidator and friends. > > > > 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%2 > B%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 > > -- > Regards, > Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
