[kde-artists] Oxygen Tab Widgets.

Hello all,

I was wondering why the scrolling in Rekonq was SO damn slow,
basically any application which uses a tab widget with at least a tab
and Oxygen.

Take konqueror for example and a debug build of Qt.

run it with QT_FLUSH_PAINT=1 konqueror . QT_FLUSH_PAINT shows what Qt
redraws in yellow. Open two tabs. Navigate to google.com and make a
search (so the scrollbars appears). Scroll and you will see that the
entire widget in the middle (the web page) is repainted. It should not
be like that, because QWidget has a mechanism to handle scrolling way
better, by invalidating only the exposed areas. This bug does not
happen with any other style (plastique and so on). It happens in all
KDE more or less.

I tracked down the problem to QRect Style::tabWidgetTabPaneRect( const
QStyleOption* option, const QWidget* ) const in
kdebase/kstyles/oxygenstyle.cpp

l1663  r.setTop( r.top() + qMax( tabOpt->tabBarSize.height() /*-
overlap*/, 0 ) ); there is this overlap thing. If I remove it then
everything works as expected. Unfortunately this is not right fix but
I was wondering what is this overlap thing?

If you take the small app attached, you can clearly see with
QT_FLUSH_PAINT=1 that when you hover a tab in Oxygen the repainted
area is overlapping the content (the actual web view). This is really
wrong and it should not be like that. The two thing MUST not overlap
otherwise it will confuse the backing store of Qt and its
optimizations.

Now I don't have the required skills to fix oxygen the right way but I
believe some of you guys can. I'll be happy to help like I did to
track down the problem so we can have decent apps :D.

Thanks.

PS: Please keep me in CC I'm not registered to kde-artists.

______________________________________________________________________________
[email protected] |  https://mail.kde.org/mailman/listinfo/kde-artists