The important difference between -9 and -10 here is the fix for issue 107945.

So it's actually a KDE VCLplug problem. Reassigning to gsl.

.

> 

submitter says:

"Additionally, I also /don't/ see this bug on i386 -- I tested on another box    
and OO Writer 3.2.0-10 seems to work fine with the Plastique theme there."

Please note, I misreported part of the problem; this is not an issue that is
part of stable OpenOffice 3.2.0, but rather and issue in OpenOffice 3.3, as it
was a fix within v3.3 that was backported to v3.2.0 that seems to cause this issue.

The problem happens for all other kde44-widget styles (CDE, CleanLooks, MSW95Look, Motif, Plastique) 
but not for Oxygen.

As Rene already mentioned, it is related to the fix for the issue #107945 and
the code:

--- cut ---
        int size = kapp->style()->pixelMetric(QStyle::PM_LayoutLeftMargin);
        pTempClipRegion = XCreateRegion();
        XRectangle xRect = { widgetRect.left(), widgetRect.top(),
widgetRect.width(), widgetRect.height() };
        XUnionRectWithRegion( &xRect, pTempClipRegion, pTempClipRegion );
        XLIB_Region pSubtract = XCreateRegion();
        xRect.x += size;
        xRect.y += size;
        xRect.width -= 2* size;
        xRect.height -= 2*size;
        XUnionRectWithRegion( &xRect, pSubtract, pSubtract );
        XSubtractRegion( pTempClipRegion, pSubtract, pTempClipRegion );
        XDestroyRegion( pSubtract );
--- cut ---

QStyle::PM_LayoutLeftMargin is 9 in Plastic, so the xRect.height overflow for
too small widgets and X-server is not happy with it.

pTempClipRegion defined are area above the frame border. PM_LayoutLeftMargin
does not work well. I suggest to use PM_DefaultFrameWidth instead.

Also, I suggest to add check for the overflow.

I'll attach a patch that solved the problem here.

Created attachment 69993 [details]
Proposed change.

Thanks for the patch ! And just when my own install set is almost ready after
all :-)

will commit to CWS ooo30gsl01 (slated for 3.3)

Sorry, but this gives us back a paint error with frames (if I remember this is
the reason why originally QStyle::PM_LayoutLeftMargin came into play). In the
oxygen theme look e.g at a new writer document; you see that the native border
around the document is not actually drawn and you get a paint error.

Now we have QStyle::PM_DefaultFrameWidth for the frame width which came in with
issue 111464 and I get this paint error - which seems to have escaped my notice
when I committed to CWS vcl111, sorry.

The patch actually preventing the invalid region is correct, but I think in case
the rectangle gets degenerate, we could skip the whole
XCreateRegion/XSubtractRegion code.

@kendy: any input on the PM_DefaultFrameWidth thing ?
@pmladek: ok with skipping the region subtracting in case the rectangle has
height or width 0 ?

If we use QStyle::PM_LayoutLeftMargin, we will not see the status bar in most
KDE4 themes. It is too wide and it replaces the useful content there.

Hmm, I see the border in the new Writer window with the Oxygen theme with my diff.

I think that the important difference is the "+1" in
int nFrameWidth = kapp->style()->pixelMetric(QStyle::PM_DefaultFrameWidth) + 1;

I do not like magic constants. A better solution might be to get the real border
width via QFrame:frameWidth(), see
http://doc.qt.nokia.com/4.6/qframe.html#frameWidth-prop. Though, I am not
mistaken, we do not have the real QT widget available in the method.

The "QStyle::PM_DefaultFrameWidth) + 1" looks like a good compromise. It works
well in many themes. In each case, I think that the content is more important
than the border ;-)

Created attachment 70009 [details]
screenshot with PM_LayoutLeftMargin

Created attachment 70010 [details]
screenshot with PM_DefaultFrameWidth+1

Attached two screen shots that illustrate the results on OpenSuSE 11.2 with the
oxygen theme. The frame in the PM_DefaultFrameWidth+1 is a paint error.

Now in status bar there is no frame anymore since issue 108321 got integrated in
3.3, so that problem vanishes.

pmladek->pl: Sigh, I have missed this. I do not see the messy white border here,
so it is less visible.

Do you have any idea about a better solution?

Ah, I have missed the note about the issue #108321. If the status bar border was
removed, QStyle::PM_LayoutLeftMargin might be fine after all.

If I paint the status bar items bordered again, DefaultFrameWidth+1 does not
work right either, the frames are clipped. I think the frame is actually larger
that 2 pixel in that Oxygen theme.

Actually I hoped kendy has insight. I tend to go with reverting to
PM_LayoutLeftMargin, but that would undo kendy's change of issue 111464. Which I
assume he made with good reason.

pl: So, I believe QStyle::PM_Layout(Left|Right|Top|Bottom)Margin values are
completely wrong in the context of getNativeControlRegion(), they define the
spacing in layout, ie. _between_ the widgets, not inside them.

To me it seems that the correct way would be to use QStyleFrameOption for frames
(and similarly for edit boxes), and get the information from there (ie. even my
QStyle::PM_DefaultFrameWidth is not 100% perfect).

That seems sensible. Indeed creating a QFrame and asking it for frameWidth()
seems to do the trick (the value is 3 then and the paint seems ok). So I'll
change getNativeControlRegion and drawNativeControl to use that - I assume I can
cache the value.

done so in CWS ooo30gsl01

changeset at http://hg.services.openoffice.org/cws/ooo30gsl01/rev/ad9152ac9a1c

pl: Thank you a lot!  Not sure how the KDE4 plugin behaves when the theme
changes; KDE3 vclplug have been ignoring the event IIRC.

Currently the KDE4 plugin also does not react on theme changes.

can anybody please verify this issue ? If an install set is needed, I can
provide a Linux X64 one.

I will verify it later today or tomorrow. I'll do it with my build.

verified in CWS ooo30gsl01

pmladek->pl: I am sorry that it took me so long. I could confirm that the
changes are fine in CWS ooo30gsl01.

Just a nitpicking. You added "#include <stdio.h>" in
http://hg.services.openoffice.org/cws/ooo30gsl01/rev/ad9152ac9a1c. I think that
it was only for debugging and you did not really wanted to commit it.

@pmladek: thanks for verifying. I would have waited but my QA-Rep wanted to get
this CWS in before branch off. I removed the include, which is as you pointed
out a debug remnant. Thanks for finding that.

integrated in OOO330m1

closing