Version: unknown (using KDE 3.1.94 (3.2 Beta 2), compiled sources) Compiler: gcc version 2.95.4 20011002 (Debian prerelease) OS: Linux (i686) release 2.4.22 Following screen setup: +------------+-+ +--------------+ | |X| | | | Screen 1 |C| | Screen 2 | | |P| | | | |X| |== kicker ====| +------------+-+ +--------------+ CP is the child panel. If a Window on Screen 1 is maximized, it is hidden behind the child panel.
Created attachment 3824 [details] Screenshot which shows the setup. Child Panel is on screen 1
*** Bug 66954 has been marked as a duplicate of this bug. ***
Still there in 3.2.2 (Debian sid/i386 packages) Extracts from xdpyinfo: vendor string: The XFree86 Project, Inc vendor release number: 40300001 XFree86 version: 4.3.0.1 screen #0: dimensions: 2048x768 pixels (722x271 millimeters)
I'm using Xinerama with two screens. I'm running Debian sarge with kde 3.3.2 (deb versions are 3.3.2-1) I get the same problem reported above with my main panel when it's on either of the common edges. If the panel is on any of the 6 'outer' edges it behaves correctly. (window maximisation, that is) Extracts from xdpyinfo (coz Daniel did): version number: 11.0 vendor string: The XFree86 Project, Inc vendor release number: 40300001 XFree86 version: 4.3.0.1 screen #0: dimensions: 2432x1024 pixels (617x260 millimeters)
*** Bug 102647 has been marked as a duplicate of this bug. ***
In KDE 3.5.1 / SUSE Linux 10.1 beta9 the behaviour has changed: - the panel is always respected when resizing windows :-) - you can't move windows to the other screen if there's a panel in the middle :-(
Using KDE 3.5.6 on openSUSE 10.2 I have the same problem as Christian. My setup is a vertical big desktop with screen 1 above screen 2 and kicker at the bottom of screen 1. I can't move windows to the second lower screen.
I've made a simple patch/workaround which fixes my problem so far. I don't know if it's ok, so any kwin developer should review this patch. I've made it against openSUSE KDE packages, which already come with other xinerama patches, but it merges fine with 3.5 svn branch also. If there is a panel between two screens, i'm able now to move windows between these screens. With xinerama disabled, the behaviour is the old one.
Created attachment 19964 [details] fix xinerama panel blocking while moving windows
The original problem has been already fixed as far as I can say. But I cannot reproduce the problem with not being able to move windows. What are the steps to reproduce?
Of course your are right, the orginal problem was already fixed. I just replied to Christian Boltz (comment #6). The new problem is, that it's not possible to move windows between 2 xinerama screens if there is a panel (like kicker) between them. As I said before, I've a vertical xinerama layout with screen 1 above screen 2 and kicker placed at the bottom of screen 1. I can't move a window to the second lower screen completely, because it stops when the window titlebar reaches the kicker panel.
The patch is not right, WorkArea needs to be computed properly, bug is either in Client::adjustedClientArea() or in Workspace::updateClientArea().
I just tested this again with KDE 3.5.7 release 2.1 (from openSUSE buildservice). It seems this bug is fixed. With a panel in the middle of my xinerama setup, - I can move windows across the panel - maximized windows respect the panel I'm not sure about comment #12, but from my POV this bug is fixed :-) and can be closed as such.
Ok.
Created attachment 97621 [details] screenshot of buggy behaviour I have the problem initially described with KDE 4.13.3 (Kubuntu).
No idea about the resolution of this bug, but it looks a lot like - and you are you're facing - bug #94470 The panel is ignored because it doesn't set a strut and it doesn't set a strut, because it must not do so. NETWM completely ignored multiscreen scenarios and discussions about this have been frustrating (to put it nicely) - this will likely be different with the vendor lock-in designed wayland (but in return, you'll prospectively live in a gnome-only or kde-only world - and of course, we then can just do as it pleases us)
Thanks for the quick reply. That made me realize that I already co-reported that a while ago, in the bug you linked. Since this is not looking like ever getting fixed in KDE 4, I recommend those affected to take a look at a possible workaround: https://bugs.kde.org/show_bug.cgi?id=167852#c66