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.

>
> 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

-- 
Regards,
Konstantin
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to