[Development] Moving Qt's undo framework out of Qt Widgets
mitch.curtis at qt.io
Wed Apr 5 11:33:28 CEST 2017
> -----Original Message-----
> From: Konstantin Tokarev [mailto:annulen at yandex.ru]
> Sent: Wednesday, 5 April 2017 11:29 AM
> To: Mitch Curtis <mitch.curtis at qt.io>; development at qt-project.org
> Subject: Re: [Development] Moving Qt's undo framework out of Qt Widgets
> 05.04.2017, 12:24, "Mitch Curtis" <mitch.curtis at qt.io>:
> > 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
> Out of curiosity, why does this code have to be in QtGui? Looks pretty-much
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
> > 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)."
> > 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