Unable to influence rendering of selected items using Qt::ItemDataRole
Dear Qt Users/Experts,
I have managed to influence the renderering Foreground and Background in my QTableView. It is unfortunate that the one cannot use the model to give hints concerning the rendering of selection, as no Qt::ItemDataRole exists that support this.
Is there a way in which the model could give hints as to preferred rendering (as with the non-selected rows/columns/fields).
I realize that I can influence rendering by overriding QStyledItemDelegate, but I'm not sure whether I can influence "selection" rendering in this way. It would seem consistent to be able to influence both selected and non selected item's rendering from the model. Is this a Qt ommission?
Any comments, hints or help would be welcome.
andre last edited by
You could considder using a stylesheet instead?
Please ignore my previous post. The Image did not work and I can't edit it for some reason.
[quote author="Andre" date="1319113470"]You could considder using a stylesheet instead?[/quote]
We need to modify colours and font of specific cells in the table iaw. model parametric data e.g.
Using Qt::FontRole, ForegroundRole and BackgroundRole works well for this. Unfortunately nothing exists that enables one to modify the "selected row" (one wants to indicate selection, but still differentiate between look and feel of cells based on parametric data). I realize you can change the general selection colours by modifying stylesheets, but this cannot modify specific cell colours and fonts based on parametric data (and considering selection state).
One would imagine that if Qt gives one the ability to give hints concerning background/foreground/font etc via the model (as result of parametric change), it would be able to do so for selection colours also. Is this an omission? Don't you consider the fact that Foreground/BackgroundRole is influential from the model but selection is not, as inconsistent?
andre last edited by
You will need to use a delegate to make the rendering work the way you want it, based on the "model parametric" data and the selection state.
Design perspective reply
Well, to be honest, the very existence of the rendering-related data roles is inconsistent. IMHO, it doesn't belong in the (core) model to begin with, it should be up the delegate to determine the rendering, as indicated above. Data is in de model, the view controls the layout, and the delegate dictates the rendering. However, I think that the current way to do this (subclass the delegate) is much to complex for such a simple and often-requested task. I guess that is the reason these roles exist in the first place, but it is not the ideal or the most flexible solution. I have experimented with using style sheets in past, and that worked but the code was not all that efficient or elegant in places, and I had trouble making it work together with the style.
Please edit your post if you want to change it, instead of just re-posting the entire thing. I have fixed your image.
[quote author="Andre" date="1319130593"]
Please edit your post if you want to change it, instead of just re-posting the entire thing. I have fixed your image. [/quote]
Thank you for the reply. I did try to edit the post. I used Mozilla ff (various versions), and for some reason on posting after the edit it did not work. I could preview and see the image after edit, but could not post. I've not been able to post from Firefox (version 3.6 and thereafter version 5) from windows XP??? I had to change rendering to explorer to post in the first place. Therefore my apology for reposting the whole thing. This I now posted from ff under linux at home and it seems to work better.
I agree that allowing roles to render seems wrong if you can't do it consistently for all kinds of rendering. We initially used a delegate for the same thing, but sometimes data exists (can exist) in the model that influences rendering, but does not form part of the actual viewable data e.g:
I have 10 parameters, 8 of which is displayed, two which influence the color and font. The column count is then specified as 8, and the delegate typically is not intimate enough with a model (and should not be) to know that non displayed data influences displayed data.
Furthermore, what lead me to using the roles for the colour, was initially the fact that my parameters influences the width of table column headers (as well as width of editors...), for this reason it is reasonable to suggest a font size from the model, as the view has no clue. Inorder to give the correct size hint I had to be aware of the font too (and at that stage only the delegate was aware of this). The model cannot request the font used from the delegate (else everything becomes too coupled).
My solution would be - keep all data (even rendering data) in the model (I suppose the model can lend from styles). If one wants rendering be different from what was specified/hinted by the model, I would then suggest a proxy model. The delegate then exists solely for the purpose of defining editor type.
- We want columns in table views to autoscale iaw the parameters in conjunction with header text: max( paramWidth, headerWidth).
- How? By determining the maximum width of a field.
- Then we require the font.
- Therefore the model needs to be font aware.
- Qt::FontRole to the rescue.
- But font role influences rendering, and with customized delegates the model cannot know the font.
- Therefore, as with StyledItemDelegate, the model dictates rendering (it has to, otherwise the design will have to change?).
Finally, delegates use item indexes, and undisplayed data (in the model) might influence rendering of displayed data. QStyledItemIndex uses model indexes as supplied by QTableView, which is determined by the visible row/col count. A general delegate can therefore not render correctly without being intimate with the model - too coupled.
Again - we need roles in the model...
I don't know if I'm making sense to you.
Kind regards, thanks again for your reply and patience.