If there is always a 1 to 1 relationship between the tree item and graphics scene item, consider using boost::bimap where the two "sides" of the map are a pointer to the QStandardItem and a pointer to a QGraphicsItem, respectively. Looking up using one as a key gives you the other, and vice versa.

Mixing up QStandardItem and QGraphicsItem by multiple inheritance seems like a good way to lock yourself into an inflexible design, and it would be a weird class - sometimes it behaves like a car, sometimes it behaves like a banana, so to speak.

It might be feasible to inherit from bimap to create a QObject that could act as the intermediary between the item model and the scene; catch signals from the model or scene, then map those into new signals emitted by the bimap and received by the other partner. This way, neither the scene nor the tree view know anything about each other - all communication is through the bimap.

Note that you can use two std::map instances instead of the bimap if you don't want the overhead of another library and learning curve. However, you have to be very careful that changes in one map's key or value get propagated to the map that works in the opposite direction so that things stay in sync.

In any case, my rule of thumb (and Qt's as well) is to decouple objects as much as possible. That's the purpose of signals and slots. No object instance knows who is listening to its signals, and no object instance knows who is calling its slots - the signal/slot pair is all that matters.