If i maximize a window, the shadow/border of the window is also on the second screen and so it is shown in the window-bar. Happens since i use "FormaN". Reproducible: Always Steps to Reproduce: 1. Install & Use FormaN 2. Use a Second Screen 3. Maximize the window 4. See it happening Actual Results: The Border is on the second Screen and the window is shown in the window-bar Expected Results: The Border is just on the first Screen and the window is only shown in the window-bar of first screen Screenshot http://img221.imageshack.us/img221/6914/windowj.png
My KDE Version is KDE: 4.9.5 "release 7"
Which decoration engine do you use? To find out, use this command in Konsole: grep PluginLib ~/.kde/share/config/kwinrc
> grep PluginLib ~/.kde4/share/config/kwinrc PluginLib=kwin3_aurorae
which theme is it?
"FormaN" -> http://opendesktop.org/content/show.php?content=141963
It's actually ony the shadow (the window has no "border" in maximized state for the config option anyway), right? That's common and in a way expected - we canot just clip shdow on the screen where the window "is not" (makes no sense when the window is eg. moved between screens) I rather assume the request is "there should be no shadow at all when a window is maximized", correct?
actually in the case of Aurorae I thought that there is no shadow at all in maximized state. At least in my opinion there should not be and I had never really noticed one. From the code: void AuroraeClient::padding(int &left, int &right, int &top, int &bottom) const { if (!m_item) { left = right = top = bottom = 0; return; } if (maximizeMode() == MaximizeFull && !options()->moveResizeMaximizedWindows()) { left = right = top = bottom = 0; return; }
I can't reproduce the behavior with a deco called "radial" - what could be is that there's a zombie shadow property on the window from eg. bespin or i think skulpture as well. @Gabriel, did you use another decoration before this one and changed it without restarting kwin?
@Thomas yes, i used the suse default before, installed and changed the new decoration after restarting the system it was still there i tried it with radial(thin borders and normal) and had the same problem i changed to another decoration without the shadow stuff and changed back to formaN and radial after that and now the problem is gone maybe some configurations aren't set on every change (maybe wrong preconfigurations after updating kde)? can't reproduce it anymore now if you want to try much, i installed opensuse 12.2 and updated it to thumbleweed, then i changed the decoration have a nice day and thanks for your quick help
Try to recause it, as soon as it happens, run xprop | grep _KDE_NET_WM_SHADOW and click the wrongly shadowed window (using some Aurorae decoration, ie. what you got via GHNS) as soon as the cursor turned into a cross. If the output is not void, there's the cause of the shadow. You could also try if the "SuSE default" (QtCurve?) sets it.
Oh, i have news! I restarted and now its there again :) So i can make it work by changing the theme to plastik and then to the one i want. While having Plastik on: > grep PluginLib ~/.kde4/share/config/kwinrc PluginLib=kwin3_plastik If i switch between some aurorae it doesn't "activate the workaround". But if i restart my OS the problem is back
Hi Thomas, it doesn't have a shadow it seems, maybe is just the first pixel of the background image which is darker.. i saved both xprop's (working = no bug and not working = with bug) hope that helps to get a step closer tell me if i can give you any information :) thank you again
Created attachment 76327 [details] Output of xprop without bug
Created attachment 76328 [details] Output of xprop with bug
Created attachment 76333 [details] kwinrc, when it's broken
If i execute this, it also works well Something have to be different to the normal startup > kwin --replace OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL version string: 3.0 Mesa 8.0.4 OpenGL shading language version string: 1.30 Driver: Intel GPU class: Unknown OpenGL version: 3.0 GLSL version: 1.30 Mesa version: 8.0.4 X server version: 1.12.3 Linux kernel version: 3.7.1 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes
please do a: qdbus org.kde.kwin /KWin supportInformation when it's broken. That provides all the settings, not just those in kwinrc.
i checked it, but there is no differenz between them except that kwin4_effect_dialogparent is active.. but i found out something new: If i start a new program (with a window) after doing the kwin --replace and maximize it, then the bug appears, but if the window was maximized before kwin --replace the but doesn't appear (if the window is opened and wasn't maximized yet the bug appears also) if i remove the maximize and do it again, the bug is like before (so it seems to be anything which got saved from kwin startup here) can i give you any debug log that could help?
Created attachment 76838 [details] supportInformation with Bug
Created attachment 76839 [details] supportInformation without Bug
When the problem appears, does moving around a window (or otherwise update the screen) /below/ the shadow "fix" it?
moving a window around (did it below and between the screens) doesn't help.. how do i update the screen? i'm in irc with martin, if you know anything i could do for debugging you can also tell me "on the short way".. since i did read that you don't know irc so good here is a direct-link http://webchat.freenode.net/?channels=kde&nick=tluebke .. i will see you, if you connect :) .. i will be there for the next 2-3 hours
(In reply to comment #22) > moving a window around (did it below and between the screens) doesn't help.. > how do i update the screen? > > i'm in irc with martin, if you know anything i could do for debugging you > can also tell me "on the short way".. since i did read that you don't know > irc so good here is a direct-link > http://webchat.freenode.net/?channels=kde&nick=tluebke .. i will see you, if > you connect :) .. i will be there for the next 2-3 hours oh sorry http://webchat.freenode.net/?channels=kde&nick=tluebking is the right link :)
Problem solved: if (maximizeMode() == MaximizeFull && !options()->moveResizeMaximizedWindows()) { left = right = top = bottom = 0; return; } You don't have moveResizeMaximizedWindows disabled - whether the setting should be relevant or not, i can't say. -> Martin? However, i still want to remove it for (now) 4.11 and we'll have to sort out what to do with maximized windows then (eg. clip the content against the screen)
[Windows] IgnoreFocusStealingClasses=kio_uiserver MoveResizeMaximizedWindows=true ---------------- just to comment it.. that helped.. doesn't look nice if i drag a window on the right side of the title-bar, because it doesn't stick at the cursor then, but it works.. i didn't try to restart yet, but the problem doesn't appear after the kwin --replace with that config anymore
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
*** This bug has been marked as a duplicate of bug 434213 ***