Best practice for QItemDelegate (paint() needs underlying data)

Hi. I have a rather complex model derived from QAbstractTableModel. I also use a QSortFilterProxyModel for filtering. I'm able to "make it work" but I think I'm going against the Model/View paradigm. Generally, when my custom delegate's paint() routine is called, it really doesn't know how to paint that index b/c it needs information from another index. Imagine a structure that has 5 columns, and I want to paint a row red if column 0 is blank. By the time paint() is called with the index pointing to 0,1, I need to check back to the value of 0,0. Since the QModelIndex provided in paint() returns a pointer to the model, I could do this if my model were so simple. Unfortunately, it's not. There's quite a few checks that happen. As such, I need not the value of some other cell, but I need a pointer to the data structure that is represented by that cell.

Try 1: What I've been doing until now is, is giving the delegate a pointer to the underlying model & a pointer to the underlying proxy. It will communicate with both of the two to figure out exactly how that index should be handled.

Caveat 1: The delegate is expecting both a model & a proxy. Not great for a view that is just a straight view of the model (w/ no filtering). I could probably make paint() work and just ignore the proxy if it's NULL, but this still doesn't feel right.

Try 2: the QModelIndex in paint( int, const QStyleOptionViewItem, const QModelIndex ) provides a pointer to the underlying model. I can cast this to either my derived model, or my derived proxy. I still need to know which though, which doesn't make

Caveat 2: Once again, I need to know whether I'm using a proxy or not, to know what to cast it to. Thought about a super class which my model and proxy would derive from, but then this pulls in double-inheritance stuff which is no bueno.

I was thinking of making my own class which simply contains both a derived QAbstractItemModel & derived QSortFilterProxy, but only acts as one. Paint might cast it to my_own_class*, and my_own_class could have a function to retrieve a pointer to the underlying data structure in the model... but would get it via the proxy in the case it was acting as a proxy.

...or maybe I'm missing the boat altogether?

Added after 1 21 minutes:

After careful thought, I think I'm attacking this wrong.

paint() should just get data from QAbstractItemModel... Delegate should have some type of foreknowledge of how to paint which rows & columns differently, me thinks.