Qt-Copy patch - can commit ?
peter.penz at gmx.at
Thu Dec 6 19:22:34 GMT 2007
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
I'll check this today :-)
More information about the kde-core-devel