[kde-artists] Re: Oxygen Tab Widgets.

Hugo Pereira Da Costa <[email protected]>
Newsgroups gmane.comp.kde.artists
Message-ID <[email protected]>
Hi again Alex,

Just had a first look at your patch.

From my experience, the bug is triggered as soon as base_overlap is larger 
than the default frame size. namely, you can set the guy to 2 (instead of 0), 
as is done in QCommonStyle, and your dummy example repaints as expected.

You confirm ? 

Hugo

> Hello Hugo,
> 
> So I looked a bit inside Oxygen.
> 
> I did a patch (which is wrong because it does not fix all the cases
> for QTabWidget) but seems to give almost the same look as before but
> fix the scrolling issue by avoiding overlap.
> 
> Attached 3 screenshots:
> 
> - The original one (today) (number1)
> - With your line commented (number2)
> - With my patch (number3)
> 
> Also if I comment the line you said nothing happen because the overlap
> is used somewhere else. If I put no overlap like in the second diff
> attached a margin appears on top of the content.
> 
> What do you think?
> 
> On Mon, Apr 18, 2011 at 7:05 AM, Hugo Pereira Da Costa
> 
> <[email protected]> wrote:
> > On Monday 18 April 2011 12:04:21 Hugo Pereira Da Costa wrote:
> >> On Monday 18 April 2011 11:49:52 Hugo Pereira Da Costa wrote:
> >> > 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
> >> 
> >> PS: I don't have (yet) a Debug build of Qt.
> >> Could you check if the bug persist if you comment the two lines:
> >> 
> >>             case SE_TabWidgetTabContents: return
> >> tabWidgetTabContentsRect( option, widget );
> >>             case SE_TabWidgetTabPane: return tabWidgetTabPaneRect(
> >> option, widget );
> >> 
> >> in oxygenstyle.cpp ?
> >> this should fallback to QCommonStyle implementation, will raise more
> >> bugs in some applications, but might give me more clue about what's
> >> going wrong.
> >> 
> >> (note: maybe you can also try just commenting the first)
> > 
> > argh. Sorry. I meant: just the second, namely
> > case SE_TabWidgetTabPane: return tabWidgetTabPaneRect( option, widget );
> > 
> > They should be around line 880 and 881
______________________________________________________________________________
[email protected] |  https://mail.kde.org/mailman/listinfo/kde-artists
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.