This looks like a KDE4 backend problem. Doesn't happen with we GNOME backend.
For me not only this Window is transparent, but the whole application stops processing (internal?) X11 (paint?) events (just move the window).
If I close the dialog by guessing the button or pressing ESC, everything continues to work fine...
Actually for me it just happens, if LO has some content in the clipboard (probably again a QClipboard problem).
And it just happens with this modal dialog. I've tested other dialogs, which using the same class (SfxTabDialog), but these don't freeze.
Currently I'm investigating, what makes this particular dialog so special. All threads are actually Yielding, nobody seems to wit for a lock - very strange.
This looks like a KDE4 backend problem. Doesn't happen with we GNOME backend.
For me not only this Window is transparent, but the whole application stops processing (internal?) X11 (paint?) events (just move the window).
If I close the dialog by guessing the button or pressing ESC, everything continues to work fine...
Actually for me it just happens, if LO has some content in the clipboard (probably again a QClipboard problem).
And it just happens with this modal dialog. I've tested other dialogs, which using the same class (SfxTabDialog), but these don't freeze.
Currently I'm investigating, what makes this particular dialog so special. All threads are actually Yielding, nobody seems to wit for a lock - very strange.