[kde-artists] Re: Oxygen Tab Widgets.

On Tue, Apr 19, 2011 at 2:00 PM, Hugo Pereira Da Costa
<[email protected]> wrote:
> 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.

Not sure to get what you say :D

a diff perhaps will help me :D.

>
> 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