Qt-Copy patch - can commit ?

[Peter Penz]

Hi Fredrik,

On Thursday, 6. December 2007 19:41, Fredrik Höglund wrote:
> On Thursday 06 December 2007 19:00, Fredrik Höglund wrote:
> > On Thursday 06 December 2007 14:13, Rafael Fernández López wrote:
> > > Hi,
> > >
> > > I would like to know if I can commit the attached patch.
> >
> > No - this patch can't possibly fix the problem.
> >
> > The palette in the view options is set in QStyleOption::init(), which is
> > called by QAbstractItemViewPrivate::viewOptionsV3(), which paintEvent()
> > calls right at the start of the function before entering the loop.
>
> Having analyzed the problem a bit more, the real problem seems to be that
> Dolphin creates a QStyleOptionViewItem object as a member of each view
> and calls viewOptions() in the base class only once in the constructor
> to initialize it.

Thanks for the analyzes!

> The views reimplement viewOptions() to return this cached object, and
> only updates the object when a setting in Dolphin is changed.
>
> The problem with this approach is that when a setting is changed and
> Dolphin is unaware of it (which happens when the global palette, fonts
> or indeed even the focus of the widget is changed), the cached object
> becomes out of sync with the actual configuration of the view.
>
> I think it would be better to always create the view options on the stack
> in paintEvent(), and let Qt initialize it from the view's settings, rather
> than reimplement this logic in Dolphin.

I generally agree, but I think doing this in the paintEvent() is not enough. 
Dolphin overwrites QStyleOptionViewItem QAbstractItemView::viewOptions(), 
which is used by QAbstractItemView as base initialization for the layout + 
drawing code. I think instead of returning the cached QStyleOptionViewItem 
m_viewOptions inside DolphinXxxView::viewOptions() I'll fetch the instance 
from QAbstractItemView and will modify only the settings Dolphin wants to 
have adjusted.

I'll check this today :-)

Bye,
Peter