Version: (using KDE 4.3.0) OS: Linux Installed from: Fedora RPMs This was originally reported to redhat (https://bugzilla.redhat.com/show_bug.cgi?id=506984). They came to the conclusion that it was a problem in kwin. Original problem description: when multiple monitors are set up, openoffice.org impress won't show slideshow properly. it creates a window over one of the screens (whichever it is set to in slide show settings) that cannot be moved or closed (except with xkill), which has 2 scrollbars, but isn't updated (so it keeps whatever was drawn underneath). scrolling moves the garbage around, but no slides are shown. escape, clicking etc doesn't work, only xkill (ctrl+alt+esc) which kills openoffice. when displaying on a different screen, the main gui can still be interacted with, but slideshow still broken as above. slideshow displays correctly when only one monitor is set up it does this even with a clean blank presentation. Version-Release number of selected component (if applicable): openoffice.org-impress.x86_64 1:3.1.0-11.3.fc11 How reproducible: always Steps to Reproduce: Run the demo program mentioned below or: 1. open openoffice.org impress 2. create empty slide show 3. slide show -> slide show (F5) Actual results: test fails with GDK_WINDOW_TYPE_HINT_DOCK window which doesn't get updated and can't be closed, with scrollbars, but no slide show Expected results: test should pass with GDK_WINDOW_TYPE_HINT_DOCK slideshow should be displayed Additional info: I'll attach a stand alone demo in a moment, authored by Caolan McNamara (see RH bug for more info) "So, like dtardon says, we're not able to force focus into the presentation window, the reasons seems to be KWin's handling of windows with GDK_WINDOW_TYPE_HINT_DOCK where we never get focus for such a window."
Created attachment 36556 [details] standalone demo test case by Caolan McNamara (see https://bugzilla.redhat.com/show_bug.cgi?id=506984) I managed to compile with: gcc demo.c -I/usr/include/gtk-2.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/lib64/glib-2.0/include 2>&1 -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -L/usr/lib64 -lgtk-x11-2.0 -o demo the output is: work to use GDK_WINDOW_TYPE_HINT_TOOLBAR fail to use GDK_WINDOW_TYPE_HINT_DOCK
I'm agreeing with mgraesslin, the fault is in OO.o as: 1) The window in question is not a dock at all (A dock as different behavioural characteristics to normal windows, that's why it's a separate type), and 2) OO.o should not be painting on a focus event--it should be using the expose/map event instead. By the sound of it they would be better off using a normal fullscreen, always-on-top window.
1. I second Martin and Lucas It's obviously not a dock and shouldn't claim to be because it may partially match some dock attributes. 2. To not let you get lost between developers blaming each other: KWin rules support to override some attributes (Window-Specific) You should be able to force the window to - be a normal window (workarounds, window type) - be fullscreen (geometry) - keep above (preferences) - accept focus (preferences) Some combination of those (in doubt, just check all) should workaround your problem.
There seems to be a patch committed to the downstream bug