Calendar with QTableWidget and QItemDelegate

[anda_skoa]

I am pretty sure that the item goes through the delegate.

Basically the Item based views are a convenience (all-in-one) and somewhat compatibility measure (similar API as in Qt3) over actual model/view.

So the QTableWidgetItem is just a way to put some data into the internal model of the QTableWidget, all output and input is handled via the mechanism of the QTableView, e.g. using delegates.

Cheers,
_

[Binary91]

So you mean that the QTableWidgetItem::setText(QString&) function results at least in the same as directly using QPainter::drawText(...) ? Hence, at least, the QTableWidgetItem with all its functionallity is just an "easier" way to use the QPainter directly? That means, that there are no two different editors, its always the same editor, but two ways to call/disable it?
That sounds logically. That would explain why no text appears when I try to show text via QTableWidgetItem while also reimplementing QItemDelegate:aint(...) as an empty function with no executing code... If I'm right, then QTableWidgetItem::setText("Test") also calls QItemDelegate:aint(..) --> so if I reimplement this function as an empty function, nothing will appear in the table...

[anda_skoa]

So you mean that the QTableWidgetItem::setText(QString&) function results at least in the same as directly using QPainter::drawText(...) ?

No, these are two different things.
QTableWidgetItem::setText() stores a text for a given cell.
The delegate's paint() method draws contents of a cell.

Hence, at least, the QTableWidgetItem with all its functionallity is just an "easier" way to use the QPainter directly?

There is no access to a QPainter via QTableWidgetItem

That means, that there are no two different editors, its always the same editor, but two ways to call/disable it?

Where do you see different ways to enable/disable it?

That would explain why no text appears when I try to show text via QTableWidgetItem while also reimplementing QItemDelegate:aint(...) as an empty function with no executing code

If the delegate in use does not paint anything, not data will be displayed, independent of how that data is stored.

If I'm right, then QTableWidgetItem::setText("Test") also calls QItemDelegate:aint(..) --> so if I reimplement this function as an empty function, nothing will appear in the table...

QTableWidgetItem::setText() stores data inside the QTableWidget.
QItemDelegate:aint() draws data it gets from the QTableWidget-

Cheers,
_

[Binary91]

QTableWidgetItem::setText() stores data inside the QTableWidget.
QItemDelegate:aint() draws data it gets from the QTableWidget-

Ah, so the table handling is:
1. step: building the table and getting / storing all its contents
2. step: depending on the contents of step 1, informing the delegate about the contents that have to be painted

So, via QTableWidgetItem::setText(...) I can store the text and in later use, I can get information about the text again (QTableWidgetItem::text() or via index from QTableWidget directly). In contrast, the text I directly paint via QPainter::drawText(..) is not "registered" anywhere in the table (model) so I can't address it later, right??

Where do you see different ways to enable/disable it?

Well, I can use QTableWidgetItem::setFlags(..) to disable editing, and I can reimplement the QItemDelegate::createEditor and any other editor functions from the delegate and left them empty. Or am I wrong? What would happen if I mix them?
I could imagine that this handling is the same as with the text example above. I guess, the QTableWidget (or the model) informs the delegate about whether to create an editor or not, so if I disable the edit functionallity via QTableWidgetItem::setFlags(..), the delegate will not create an editor. But nevertheless, I can still create the editor via reimplementing the delegate's editor functionallity, right?

[anda_skoa]

Ah, so the table handling is:
1. step: building the table and getting / storing all its contents
2. step: depending on the contents of step 1, informing the delegate about the contents that have to be painted

More or less, yes.
You don't have to inform the delegate about anything, the view (in your case the QTableWidget) takes care of calling the delegate when necessary.

So, via QTableWidgetItem::setText(...) I can store the text and in later use, I can get information about the text again (QTableWidgetItem::text() or via index from QTableWidget directly).

Exactly.

In contrast, the text I directly paint via QPainter::drawText(..) is not "registered" anywhere in the table (model) so I can't address it later, right??

The text that the delegate retrieves via the model index is the text stored by the table widget item.

Well, I can use QTableWidgetItem::setFlags(..) to disable editing, and I can reimplement the QItemDelegate::createEditor and any other editor functions from the delegate and left them empty. Or am I wrong? What would happen if I mix them?

Well, not implementing something is not the same as "disabling".
I'd call that "broken".

I could imagine that this handling is the same as with the text example above. I guess, the QTableWidget (or the model) informs the delegate about whether to create an editor or not, so if I disable the edit functionallity via QTableWidgetItem::setFlags(..), the delegate will not create an editor.

More or less, yes.

But nevertheless, I can still create the editor via reimplementing the delegate's editor functionallity, right?

Reimplementing the createEditor() function allows you to create your own editor widget.
The decision whether to call that function is still with the view, which makes that decision based on user events, its own configuration and cell flags.

Cheers,
_

[Binary91]

Ok thanks, that makes sense. I can reimplement as much as I want, as long as the view doesn't call the editor functions, nothing will happen..

Well, one last question. In my case, I let all data draw directly via QPainter, so the data is never stored into the table. One could say, the table doesn't know, that any data exists.

How can I address this data and how can I react on user interaction with this data? I mean, I'd like to have clickable links drawn with QPainter::drawText(..), but I don't know where to ask for information when the whole view doesn't know anything about the data... How can I do that?

EDIT:
And a second question:
What is better for performance: handling the whole table design (background color, text etc.) directly via QItemDelegate:aint(...) or would it be better to create QTableWidgetItems and set the specific background colors? I mean, setting background colors via delegate would result in updating the background color each time anything happens, but that is not neccessary for me, because I set the background colors once and they are static. On the other hand, I could imagine that the delegate will do that anyway, because, as I know now, it gets the information from the table so it will repaint the backgrounds like the QTableWidgetItems orders it...

So, is there any sense in using QTableWidgetItems when I use a custom delegate anyway?

[d_stranz]

And a second question:
What is better for performance: handling the whole table design (background color, text etc.) directly via QItemDelegate:aint(...) or would it be better to create QTableWidgetItems and set the specific background colors? I mean, setting background colors via delegate would result in updating the background color each time anything happens, but that is not neccessary for me, because I set the background colors once and they are static. On the other hand, I could imagine that the delegate will do that anyway, because, as I know now, it gets the information from the table so it will repaint the backgrounds like the QTableWidgetItems orders it...

So, is there any sense in using QTableWidgetItems when I use a custom delegate anyway?

It sounds to me that what you really need is to pop up a level in the widget hierarchy and use a QTableView (instead of QTableWidget) and derive a model from QAbstractTableModel. In the model's data() method, you have control over all kinds of appearance things. See Qt::ItemDataRole. In trying to implement a delegate that jumps through all these hoops, you are essentially reinventing all of the functionality that QAbstractTableModel / QTableView give you for free.

[anda_skoa]

n my case, I let all data draw directly via QPainter, so the data is never stored into the table. One could say, the table doesn't know, that any data exists.

You are saying that your delegate uses the row and column information to get the data from a separate data structure?

How can I address this data and how can I react on user interaction with this data? I mean, I'd like to have clickable links drawn with QPainter::drawText(..), but I don't know where to ask for information when the whole view doesn't know anything about the data... How can I do that?

Well, if you get your data from some custom data structure, then why can you access it in paint() but not when handling user event?

What is better for performance: handling the whole table design (background color, text etc.) directly via QItemDelegate:aint(...) or would it be better to create QTableWidgetItems and set the specific background colors? I mean, setting background colors via delegate would result in updating the background color each time anything happens, but that is not neccessary for me, because I set the background colors once and they are static. On the other hand, I could imagine that the delegate will do that anyway, because, as I know now, it gets the information from the table so it will repaint the backgrounds like the QTableWidgetItems orders it...

Well, the painting is always done by the delegate.
Whether you use the background brush provided by via the options or decide on color based on some data in the delegate shouldn't make much difference.

So, is there any sense in using QTableWidgetItems when I use a custom delegate anyway?

As I said before, those handle different levels.
The widget item is used as an API for adding data to the table.
The delegate is painting that data.

Whether you want to handle the data via widget items or via a model is orthogonal to using a delegate to achieve a custom visualization.

Cheers,
_