I have a QStandardItemModel
in which each item is checkable. I want different slots to be called when I click on the item's checkbox, on one hand, versus when I click on its text, on the other. My ultimate goal is to have text edits, and changes in checkbox state, go onto the QUndoStack
separately.
In my reimplementation of clicked
I want to treat checkbox clicks and text clicks differently. So far, I have found no way to differentiate these events in the documentation for QCheckBox
or QStandardItem.
While QCheckBox
has a toggled
signal that I can use, I am not sure how to specifically listen for clicks on the text area.
I am trying to avoid having to set up coordinates manually and then listen for clicks in the different regions of the view of the item.
It doesn't seem this will be as simple as calling something like itemChanged
, because that only gives you the new state of the item, not the previous state. Based on previous questions, I believe you need some way to pack the previous state into the undo stack, so you know what to revert to. That's what I am aiming to do with clicked
, but there might be a better way.
This question piggybacks on the previous two in this series, in which I'm trying to figure out how to undo things in models:
Based on ekhumoro's suggestion and code nuggets, I built a treeview of a
QStandardItemModel
that emits a custom signal when an item changes. The code differentiates the text versus the checkbox changing via the role insetData
(for text, useQt.EditRole
and for checkbox state changes useQt.CheckStateRole
) :The
clicked
signal seems to be entirely the wrong way to track changes. How are you going to deal with changes made via the keyboard? And what about changes that are made programmatically? For an undo stack to work correctly, every change has to be recorded, and in exactly the same order that it was made.If you're using a
QStandardItemModel
, theitemChanged
signal is almost exactly what you want. The main problem with it, though, is that although it sends the item that changed, it gives you no information about what changed. So it looks like you would need to do some subclassing and emit a custom signal that does that:Note that the signal will only be emitted for changes made after the item has been added to the model.