kdiff3 on xfce 4.14.5, window decorations missing?

[Mark Mielke]

On Mon, Oct 12, 2020 at 5:48 PM Mark Mielke <mark.mielke at gmail.com> wrote:
> This was first encountered on Oracle Linux 8.2 + EPEL with xfwm4
> 4.14.2 + kdiff3 1.8.4 + TigerVNC 1.10.1.
>
> Sometimes the kdiff3 window decorations would be missing. I was able
> to reproduce this on Fedora 32. 50% of the time I can reproduce with:
>

This continues to happen with 4.14.6.

If I get it into the state where the maximum size is set and
repeatedly "Cancel" the pop up, File -> Quit kdiff3, and restart
kdiff3 from a terminal, it seems to alternate between two states each
time kdiff starts:

    - State 1: The decorations are presents, and no panels are covered.
    - State 2: After "Cancel" the pop up, it fills the full screen,
with no decorations, and it fully covers the Xfce panels (on the
bottom in my case).

In both states, it seems to have a high chance of exhibiting a message
like this:

    qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence:
661, resource id: 12585678, major code: 40 (TranslateCoords), minor
code: 0

Any ideas on where I should start looking?

Original steps to reproduce:

> 1) Inside a TigerVNC + XFCE session
> 2) Launch "kdiff3" with no arguments from a terminal window.
> 3) If the window + open file dialog comes up ok, first close the open
> file dialog, then maximize the kdiff3 window and try again to launch
> "kdiff3" with no arguments from a terminal window.
> 4) The main window (QMainWindow, since this is a KDE / Qt app?) is
> missing decorations. The dialog window looks fine.
>
> I found a few fixes in 4.14.x related to windows decorations,
> including a gsetting / glib corruption issue. But, the same problem
> happens with xfwm4 4.14.5 on both Oracle Linux 8.2 and Fedora 32.
>
> Any ideas of where to start looking here? I don't mind trying patches
> or even writing patches - but I need help knowing where to start. All
> the known issues seem to be addressed in 4.14.5, and don't seem to
> have fixed the problem.


-- 
Mark Mielke <mark.mielke at gmail.com>