Version: cvs (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.3.4 OS: Linux Using multihead, screen 1 is 1024x768, screen 2 is 1280x1024. Maximize Window on screen 2 works as expected with bottom border just over kicker panel. Maximize Window on screen 1 fills the entire 1024x768 area underrunning the panel which remains over the bottom 100 or so pixels. Only way to work with the maximized window is to hide the panel. Proper behavior would be for both screens to maximize properly. BTW, bug handler said the application was kcmkwinrules, but there was no ability to report for it. I am not sure the error occurs in kcmkwinoptions.
Created attachment 8547 [details] Screenshot showing maximize problem with panel on screen 1 1024x768 screenshot showing konqueror maximized to full 1024x768 dimensions underruning the panel.
I encounter the same problem with KDE 3.4 and KDE 3.3.2, with screen 1 at 1400x1050, screen 2 at 1280x1024 (to the right of screen 1), Xinerama enabled. I did some experimenting with KDE 3.4, and discovered that three of the eight possible panel positions exhibit this bug: the panel is underrun by maximized windows when it is located on the right edge of screen 1, on the left edge of screen 2, or on the bottom edge of screen 2. This problem was also reported in KDE 3.3.1 in bug 92105 which was marked as a duplicate of a non-xinerama bug which was apparently fixed in kde 3.3.2... however this problem with xinerama persists.
*** Bug 119490 has been marked as a duplicate of this bug. ***
*** Bug 110633 has been marked as a duplicate of this bug. ***
Since I recently encountered the problem, I did some investigation on the problem (windows manager standards and their internal behavior was unknown to me). It seems that the problem lies in the window manager specification, which does not define a way to describe panels reserving area in the middle of the X screen. That issue was discussed on the specification mailing list, in 2004 : http://mail.gnome.org/archives/wm-spec-list/2004-March/msg00000.html Unfortunatly, none of the proposed changes has made its way into the specification since then. Fixing this bug would require to contact people responsible for the specification in order to update it. I'm willing to participate in the process, but I'd like to know what KWin developers think about that beforehand :)
Fixed for KDE3.5.2.
*** Bug 81099 has been marked as a duplicate of this bug. ***
*** Bug 117801 has been marked as a duplicate of this bug. ***
still thesame problem (kdebase-3.5.2-0.1.fc4) Screen0 (Thinkpad T43), 1400x1050 Screen1 LCD Monitor, 1280x1024 two desktops, fullscreen on Screen1 is underneath the panel at the bottom (apparently there was no problem here before 3.5.2)
- this bugreport is about maximize, not fullscreen. Please don't reuse old fixed bugreports for unrelated issues. - it works just fine here, so when reporting your problem, you may want to say more than just "still the same"
Created attachment 16645 [details] Browser maximized underneath panel
* sorry - it was "maximize" what I meant (but didn't write) * I attached a screenshot similar to the one in the first comment
Attach: - output of "xprop -root" - output of "xprop" and clicking on the window - output of "xprop" and clicking on the panel What are your xinerama settings in kcontrol?
Created attachment 16709 [details] output of xprop on root, maximized window, and panel output of xprop on root, maximized window, and panel attached kcontrol, Desktop, Panels, Screen, Xinerama Screen: 2
.
I'm having the same problem here. Kubuntu Dapper w/ kde 3.5.4 The problem did not appear with the first 3.5 versions. It started appearing with 3.5.2 if I remember correctly. I'm attaching the xprop outputs
Created attachment 17414 [details] Output of xprop This file contains the output of the three suggested xprop invocations. It is on a 1280x1024 external flat panel on a notebook with an ATI card. The internal monitor is 1920x1200.
I forgot to mention an important point: I'm not sure I'm really using xinerama. I have two distinct X screens, each one with its independent Panel, K menu, desktop switcher, system tray, and so on. I cannot drag a window from one screen to the other. A funny detail: when I go to system settings/Panel, in the arrangement tab there is a xinerama section with an Identify button for identifying screens. When I press it, two big labels numbered 1 and 2 appear... on the same screen: when I open the system settings on screen 1, they appear on screen 1, and when I open system settings on screen 2, they appear on screen 2.
I cannot reproduce this with multi-head xinerama on Gentoo using 3.5.4 and an NVIDIA graphics card
*** Bug 133831 has been marked as a duplicate of this bug. ***
*** Bug 131026 has been marked as a duplicate of this bug. ***
I'm getting this bug also on Kubuntu 6.06 (KDE 3.5.2). I'm running two seperate X screens (1280x1024 & 1024x768) and not using Xinerama or TwinView (I'm using an nvidia driver). Windows on the smaller screen underrun the panel when maximised (panel is at the bottom of the screen), so as a work around I've got the panel at the top of the screen (where this bug doesn't happen).
The problem is still there. I looked at the code (trunk and 3.5 branch) and I see something that annoys me. I see too much desktopwidget->geometry(); calls instead of desktopwidget->screenGeometry( screen ); as the code should handle only the client wich are sticked to a given screen, I don't see a reason we should rely on the KWin default screen (which should be :0.0 by default). I am not sure of this but I think the problem lies in the Workspace::clientArea method, which does: int screen = desktopwidget->screenNumber( p ); this seems wrong in the context of multiple desktop, since we have completely separated coordonate systems. Therefore it's impossible to guess the screen using this call when not in a virtual desktop.
Using default screen should be fine, since in non-xinerama multihead kwin is forked once per screen.
Thougth I agree using a forked kwin is working quite fine, I think it's not elegant, since we should not fork. Anyway this call is just wrong in multihead, in the logic of Workspace::clientArea: int screen = desktopwidget->screenNumber( p ); I think it should looks more to something like: int screen = desktop->isVirtualDesktop() ? desktopwidget->screenNumber( p ) : desktopwidget->primaryScreen(); As the first call will most probably allways return the first screen as the correct screen, even thougth we are on the secondary screen.
As this bug report seems to be getting a bit of momentum, I'd like to ask a question: would it be possible to use xinerama AND have multiple panels/desktop switchers? I like each screen having its own desktop switcher: I find it very practical to be able to switch the desktop on one screen and have the other screen stay at the same desktop, which is the current behavior with multihead. However I miss the ability to drag windows between screens available with xinerama... Would it be possible to have the best of both worlds?
Comment #25: You're welcome to contribute patches. Non-Xinerama multihead support in KDE is unmaintained. Comment #26: Not now. See bug #107302.
I made a one liner patch with the change I said and it worked :D I will have some guys in the distro I use to test if it doesn't broke in some of their configuration, and if it works I'll commit it (trunk and branch), and close this bug.
Created attachment 19317 [details] Fix for broken maximisation(and maybe more) with mutiple head without xinerama This patch fixed the problem for me and was tested on another machine. If you can try to test it before I commit it (in ~2 days) and if you have any objections contact me.
SVN commit 625468 by hermier: Fix for multihead, now maximisation works. CCBUG:94470 M +1 -1 geometry.cpp --- branches/KDE/3.5/kdebase/kwin/geometry.cpp #625467:625468 @@ -210,7 +210,7 @@ if( desktop == NETWinInfo::OnAllDesktops || desktop == 0 ) desktop = currentDesktop(); QDesktopWidget *desktopwidget = KApplication::desktop(); - int screen = desktopwidget->screenNumber( p ); + int screen = desktopwidget->isVirtualDesktop() ? desktopwidget->screenNumber( p ) : desktopwidget->primaryScreen(); if( screen < 0 ) screen = desktopwidget->primaryScreen(); QRect sarea = screenarea // may be NULL during KWin initialization
I just installed KDE 3.5.6 and the issue is still here. Was the patch included in this release?
No.
FYI: with 3.5.6 (Ubuntu) I've got """ ASSERT: "!( vertical && horizontal ) || ((( max_mode & MaximizeVertical ) != 0 ) == (( max_mode & MaximizeHorizontal ) != 0 ))" in /build/buildd/kdebase-3.5.6/./kwin/geometry.cpp (1867) """ Probably during exiting from beryl (Only when using beryl I get windows under my panel (which I have at the top) - this may be related).
Seems it has been fixed in 3.5.7. Should the bug be closed?
Closing as fixed.
I think this bug is back in 3.5.9, could a dev please test this? On my gentoo systems with 3.5.8 this worked properly, now with 3.5.9 the bad behaviour seems to be back.
pardon me, ignore my last, it seems to be a Gentoo specific patch that removes the code to handle this correctly. I'll report it downstream.
My 3.5.9 setup is fine, but this bug appeared in 3.5.10. I have dual head setup with NO xinerama. First screen is 1440x900 and second is 1680x1050. When I maximize program on second screen or make it full screen, it only uses 1440x900 area instead of all screen.
Created attachment 49163 [details] Wrong maximization in kde 4.4.5 Bug is still there. I use kde 4.4.5 and xrandr. When panel is in the left of right screen, maximization works wrong.
Created attachment 69335 [details] same issue with kde 4.7.4 I have the same issue with kde 4.7.4 (see attachment). When attaching an external monitor right of the primary one, the panel on the right side of the primary monitor gets underrun when maximizing windows. Both screens have resolution 1440x900. I don't know which dual head mechanism is used, but the graphics hardware is the integrated one of a Core i5 with default Ubuntu 11.10 drivers, setup was done in KDE system settings.
*** Bug 167852 has been marked as a duplicate of this bug. ***
See comment #5 for why this more or less won't/can't fix.
*** Bug 308024 has been marked as a duplicate of this bug. ***
*** Bug 312906 has been marked as a duplicate of this bug. ***
In 4.10 this bug still exists. Can please somebody do something about this?! Its so annoying that I cannot have my applications maximized because of this... PLEASE PLEASE PLEASE fix this issue!
this /cannot/ fix. see bug #299247 and comment #5 here and the bug linked in 299247
(In reply to comment #45) > In 4.10 this bug still exists. Can please somebody do something about this?! > Its so annoying that I cannot have my applications maximized because of > this... PLEASE PLEASE PLEASE fix this issue! Not a fix, but until the status quo changes, the workaround suggested in bug 167852 does the trick.
*** Bug 182625 has been marked as a duplicate of this bug. ***
I updated KDE to 4.11 (openSUSE 12.3) and it seems this bug has been fixed! Developer(s), who fixed this bug, thank you so much! It was the most annoying bug in KDE for me. I propose to change bug status to FIXED.
tl;dr: Please provide the output of "xprop | grep -i strut" on the inner panel. (In reply to comment #49) > I updated KDE to 4.11 (openSUSE 12.3) and it seems this bug has been fixed! No. First off: THIS CANNOT BE FIXED! It's a defect in the specification, the specification needs to be updated to be multiscreen capable, then be implemented. No, i cannot just write sth. into the NETWM spec and after one dance with the gnome fraction, i'll personally never try again. There are three possible WORKAROUNDS to this issue: ----------------------------------------------------------- 1. Using an orthogonal panel, ie. a very high and slim horizontal panel that looks like a vertical one. (You can do this yourself) 2. Have panels strut across the entire different screen, ie. as far as the maximization area is concerned, the panel covers the entire other screen and the part of the actual screen, where it's visible. (Panel iplementations -like the plasma panel container- need to do this) 3. Follow the approach of this patch https://bugs.kde.org/attachment.cgi?id=69951 to read struts differently (screen dependent instead of root dependent) Each and every workaround is for now a violation of the NETWM spec. 1 & 2 can make the other screen completely inaccessible (Ie. windows don't show up there and cannot be moved there or moved around there) KWin is "generous" in this regard, but if you do this and another NETWM compliant WM "has trouble" in this regard, it is NOT the other WMs fault. 3 is a clear violation of the spec by the WM and in addition needs panels at inner screen borders to set struts at all and to set them in screen coordinates (a smarter extension would be to guess whether that strut is screen or root window relative) but less troublesome (WM controlled implies that the WM can somhow handle inner struts) The plasma panel containment does NOT set any strut when placed onto an inner screen edge here, so whatever you observe is either one of the workarounds (eventually patched in by SuSE) or the result of a bug. Thus please provide the struttin information of the panel, so we can figure what's really going on there. Thanks.
Thank you for detailed answer, Thomas. As a developer I understand what specifications mean. I thought that one of following happened but nobody wrote about that there: - specifications have been changed; - somebody found satisfiable workaround; OK, I have 2 displays: 1920x1080 (with vertical panel on the left) on top of 1366x768. Output: $ xprop | grep -i strut _NET_WM_STRUT(CARDINAL) = 72, 0, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 72, 0, 0, 0, 0, 1079, 0, 0, 0, 0, 0,
(In reply to comment #51) > OK, I have 2 displays: 1920x1080 (with vertical panel on the left) on top > of 1366x768. Err... that's no problem anyway. From the struts you can expect the panels to stay away 72px from the left border of the combined screen and 0px from the top border of the combined screen and be 1080px high. This bug is about |----------------||----------------| | || | | || | | || | |----------------||----------------| And the "||" panel does not strut. Whatever problem there was before with your panel has been a solvable bug, pot. wrong strut geometries on the panel or so.
Confirm. Bug exists :( My bad. I understand why I wrongly reported about fixed bug. I had problems with my current configuration of displays and panel (vertical) in KDE 4.10 (I don't remember exactly which, it doesn't matter), and because of that I had to switch to horizontal panel orientation. There came this bug. When KDE 4.11 with integrated kscreen come out I decided to try it and make configuration as I have now. It worked fine (kscreen is definitely better, than previous configuration module) and I happily wrote about fixed bug there. I mixed up with bugs, sorry.
Why is this marked as WONTFIX? It seems that this means that KDE has effectively no support for multi-monitor setups nor it will ever gain any such support until some standard nobody wants to write is implemented. To the other users, who might already have abandoned KDE: what do you use now?
> To the other users, who might already have abandoned KDE: what do you use > now? please do not answer to this as that is clearly off-topic. I also want to remind everybody about KDE's Code of Conduct [1] given that the last comment was clearly out of bounds. [1] http://www.kde.org/code-of-conduct/
YES Martin, it might be a validation but why doesn't anybody from the NETWM listen to the community and do something about this stupid spec. It seems outrageous that there are a lot of guys who are having this problem and everybody is hiding behind this idiotic spec. ANNOOOOOYING
> why doesn't anybody from the NETWM > listen to the community and do something about this stupid spec. It seems > outrageous that there are a lot of guys who are having this problem and > everybody is hiding behind this idiotic spec. And why does nobody who cares about it (read the people commenting to this bug report) take the spec, prepare an update and propose it to the netwm spec mailing list? Open Source doesn't mean sitting back and complaining, open source has always been about scratching your own itch. Why is nobody of the devs working on it? At least I think it's pointless with Wayland in front of the door to even think about touching the NETWM spec ever again. It has its faults, we know them and there is no good point in fixing them after all those years when we could just transit to the next windowing system.
Sorry about that. I didn't know about the wayland transition. I watched your presentation http://community.kde.org/images.community/0/01/KWin_Wayland.pdf and I must say now I can see why nobody wants to have anything to do with the NETWM specs. I saw in the timelines some dates thrown on 2012 summer about a first release. After some digging I also saw that in 4.11 there is a Wayland support added. I would like to ask if its not too much, when would this bug be fixed in the wayland branch? Is there a release schedule for it already? Thank you
*** Bug 326136 has been marked as a duplicate of this bug. ***
So what is the status of this on Wayland? Is NETWM still an issue on it? Is there a related bug report on the Freedekstop tracker? (I couldn't find one...)
> So what is the status of this on Wayland? Is NETWM still an issue on it? No, there is no such thing as NETWM on Wayland. It will be between Plasma and KWin to handle out the strut area. KWin will know that the panel is a panel and thus can be properly included in the maximize area calculation.
Ah, so it won't be a problem there. Awesome, thanks!
April has passed, now we are in November 2014 and Wayland is still way down the road, why this bug is still present in a DE as KDE amazes me. I will try to document myself and maybe try to fix it... but I am a complete noob in KDE developing... why nobody from the team has fixed a bug that it's there since 2005? By the way I simply love KDE... that's why I'll try to help... but still... no good that such and important bug has gone unsolved for so long. Anybody who has 2 or more monitors suffers from it! Wish me luck...
And "RESOLVED WONTFIX" is not a reasonable status... "CLOSED WONTFIX" is a reasonable status...
*** Bug 340660 has been marked as a duplicate of this bug. ***
*** Bug 302282 has been marked as a duplicate of this bug. ***
*** Bug 356412 has been marked as a duplicate of this bug. ***
I just created a possible patch for Plasma/KWin combo: https://phabricator.kde.org/D2164
Git commit f5d966ee77f43b758f23eda02d879dd21442e5a2 by Martin Gräßlin. Committed on 25/08/2016 at 11:44. Pushed by graesslin into branch 'master'. Allow struts on panels between screen edges if WM is KWin Summary: KWin starting with 5.7 supports struts on panels between screen edges. Thus we can start setting struts on such panels, it won't exclude a complete screen. But we don't know how other window managers handle it and it's in general a rather "dangerous" change. Thus to not affect other window managers, we check whether KWin is running and only allow struts on thus panels if KWin is running. Unfortunately we need to test this every time we go into the code path as the WM might have changed. In case the user replaces the window manager at runtime this still can result in a bad situation. FIXED-IN: 5.8.0 Test Plan: Tested whether it works in general in X11. Further testing needed by X11, multi-screen users. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D2164 M +68 -41 shell/panelview.cpp M +1 -0 shell/panelview.h http://commits.kde.org/plasma-workspace/f5d966ee77f43b758f23eda02d879dd21442e5a2