Best app object hierarchy pattern for QUndoStack/QUndoCommand

[patrickkidd]

I will admit, despite writing apps for 20 years and using Qt since v1.44 in 1998, I have never been pushed to perfect the object model for QUndoStack. I am not clear on where to house the stack, e.g. in the mainwindow, in the document view, or in the data model. My pyqt5 app (of 5 years, plenty of costly tech debt) incorrectly punts and stores the stack globally for easy access. But it's not unit testable, doesn't allow for a meaningful python wheel, isn't unit testable, and on and on. Plus, there is the problem of calling setters on the data model from all over the app but needing easy access. So, two major questions:

• How do you organize the object hierarchy, i.e. where do you store a reference to the QUndoStack and provide access everywhere?
• How do you optimize code footprint for QUndoCommand, i.e. do you end up implementing a ton of subclasses that all look the same>

Here is an answer from ChatGPT, at least so far as my ability to prompt would generate: https://chatgpt.com/share/67651fd4-f538-8003-90e1-4c316c51e9fd

Cheers,
-Patrick

[SGaist]

Hi,

The answer depends partly on what your application does.
For example, a text editor will have an undo stack per document. Same for a painting application.
Taking the painting application example, would you need one global stack for the document or one per tool you are using ? Both.
There's no single universal answer to your question as it depends highly about the operations you are doing, how far does undoing go, etc.