[kde-artists] Re: Oxygen Tab Widgets.

Hello Alexis,

So I did some digging, and well, I'm not sure I have the skills to fix myself 
either. 

This "overlap" thing, corresponds to what QStyle::pixelMetrics( 
PM_TabBarBaseOverlap ) should return (so Qt knows about it).

it is used in these two methods 

Oxygen::Style::tabWidgetTabPaneRect
Oxygen::Style::tabWidgetTabContentsRect

which are what's called (by Qt) via 

QStyle::subElementRect( SE_TabWidgetTabContents ) 
QStyle::subElementRect( SE_TabWidgetTabPane )

Looking at QCommonStyle implementation for the two above, well, they don't 
differ 'much' in terms of metrics handling. (in fact I remember copying them, 
and "tuning" them with +/-1 pixels here and there to fix some bugs when dealing 
with corner cases of QTabWidget/KTabWidget handling). 

QTabWidget is (by far) the most painful widget to deal with in styling land 
and I've already spend hours (tenth's of hours) on it. (notably, there is no 
existing Qt Style that does not have one bug or another with it, in one 
possible or the other). 

I'm ok to revisit it in view of the problem you raise, but this will take time 
(and my hand are pretty full at the moment). 

Feel free to file an actual bug report to oxygen (style) with as much detail as 
you can so that it does not get lost in translation.

Cheers,

Hugo

> 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