set KItemListView m_styleOption.palette from scenes first view
Review Request #110505 - Created May 18, 2013 and submitted
The palette is currently always constructed empty, thus defaults to the application general palette what fails if the view gets a different palette. This is not "perfect" as it will not catch palette updates at runtime, but "works for me" (inverting docks at style polishment) If QGraphicsWidget::palette() was used it would probably be possible to update the palette (via QGraphicsWidget::scene())
yes, getting readable text instead black-on-black
Thanks Thomas for the patch! I'm not really familiar with anything that is related to colors - any help in this area is greatly appreciated! Could you describe briefly how the problem that you are fixing here can be reproduced? Thanks! (Just for the record: there is a bug report about runtime color changes: https://bugs.kde.org/show_bug.cgi?id=315061).
Review request changed
"Proof" by setting inverted palettes on the dock or the view container (autofilling the background of the dock is required or you'll just get white-on-white with the patch - that's expected, though and would happen with "regular" widgets as well) I didn't want to bring that up, but *every* graphicswidget keeps its own styleoption, with a (shallow) copy of the palette (and each needed to be updated) Things would be more straightforward if the painting would just resolve the scene palette instead, but i wasn't sure whether there's perhaps a particular reason for copying the palette and other stuff around. To keep the palette up-to-date filtering the graphicsview(s?) for PaletteChange events (and copying the widgets palette to the scene and eventually object styleoptions) is sufficient. If you can explain or disregard the presence of the palette in the styleoption i can provide you second patch.
Thanks for the feedback, but I must admit that I still do not understand at all what the actual problem is. My comments here might be really stupid - sorry if that is the case, but I have neither written nor ever worked with the code that you are proposing to change, and as I said, I have basically no clue about anything that is related to colors. Therefore, I prefer to understand what problem any proposed patch is trying to solve. I had assumed that you found a problem with the current code that can somehow be triggered by changing the colors in the System Settings or by interacting with Dolphin or some other part of the desktop in some way. Is that correct? If yes, please describe what this problem is. I have tried to change the colors in the settings, but I was unable to see any difference with and without your patch (I can reproduce the problem that color changes at runtime are not handled well, but this is not the point of your patch). If my assumption is wrong and you are just trying to make things more consistent for the case that a scene has a custom palette (and that case does currently not happen in Dolphin), please say so. I'm fine with such a change as well, I just want to understand what you are trying to achieve with the patch. Thanks and sorry again if my comments are stupid.
All right, thanks for the detailed explanation! I agree that this makes sense then. I have two small comments concerning the code, see below. Thanks for your work!