Description of problem: When running xmonad with the MATE desktop, numerous applications don't redraw properly - interacting with them has effects behinds the scene, but their window is frozen on the old contents, until switching to another workspace and back forces an update. Version-Release number of selected component (if applicable): xmonad-0.11-9.fc20.x86_64 xmonad-mate-0.11-9.fc20.x86_64 mate-session-manager-1.6.1-4.fc20.x86_64 mate-settings-daemon-1.6.2-2.fc20.x86_64 mate-desktop-1.6.2-1.fc20.x86_64 mate-desktop-libs-1.6.2-1.fc20.x86_64 How reproducible: Every time, for me anyway. Steps to Reproduce: 1. Log in to xmonad-mate desktop 2. Run any of the following - Network Manager | Edit Connections... - virt-manager - rhythmbox - various others Actual results: Application window stays frozen and does not update as you click or type in it. Expected results: Application window updates normally Additional info: Killing xmonad, then running "marco --replace" results in applications that redraw again. Interestingly, after doing that killing marco and restarting xmonad with "xmonad --replace" leaves the windows redrawing correctly, now under xmonad. Killing xmonad, then running "xmonad --replace" without running the other WM in between does *not* fix the behaviout though.
Hmm I wonder if xmonad-mate needs to run some process to help or if it marco that is helping.
Taking this since I did the xmonad-mate hack. :)
I wondered about that. I did an strace of the marco process, and couldn't see it spawning off any other helper processes. Would that strace output, or some other log from the marco run help you?
Oh, sorry, should have mentioned that temporarily running metacity also fixes things afterwards, so it's not something purely specific to MATE/marco.
Is this easy to reproduce? I can edit NM connections no problem and rhythm boxes seems to work fine. This is with the default Fedora xmonad config.
Created attachment 860366 [details] xmonad configuration Well, it reproduces for me every time. But it's not obvious to me what's different between our setups that it's not happening for you. I've attached my xmonad.hs, in case that provides a clue, although since it works with this config after running marco, I don't see how that would be related. Let me know any other information which might be helpful
(In reply to David Gibson from comment #6) > I've attached my xmonad.hs, in case that provides a clue, although since it > works with this config after running marco, I don't see how that would be > related. Can you try moving your xmonad.hs out of the way and restarting xmonad to test the default config? It might be related to your setting LG3D or your evHook. So testing without those would also be a good idea to pin this problem.
*facepalm* Yes, the default config works. After some experimentation, I realised the problem was that I had just 'startupHook = setWMName "LG3D"' instead of 'startupHook = startupHook baseconfig <+> setWMName "LG3D"', which makes sense in hindsight. Thanks for the pointer, sorry for the noise. Btw, is there a reason that the gnomeConfig doesn't include the fullscreenEventHook from EwmhDesktops by default?
Just for other xmonad users searching a solution to this “bug” (misconfiguration): The solution is to NOT USE the SetWMName extension in order to convince Java that xmonad is "LG3D" (which is a deprecated way of working around the gray java windows). Because this SetWMName breaks GTK3-apps, see the xmonad FAQ: https://wiki.haskell.org/Xmonad/Frequently_asked_questions#Using_SetWMName Instead use the preferred method (see FAQ https://wiki.haskell.org/Xmonad/Frequently_asked_questions#Preferred_Method) and set an environment variable _JAVA_AWT_WM_NONREPARENTING=1 at startup. I did this by adding the following to my xmonad.hs: import System.Posix.Env (putEnv) and adding the putEnv line to the startup of xmonad: main = do putEnv "_JAVA_AWT_WM_NONREPARENTING=1" Now I can use all java applications and GTK3-apps. See: https://code.google.com/p/xmonad/issues/detail?id=559
(In reply to Erik Streb del Toro from comment #9) Thanks for this! - I almost missed this comment. I will update our xmonad.hs to do this. (In reply to David Gibson from comment #8) > Btw, is there a reason that the gnomeConfig doesn't include the > fullscreenEventHook from EwmhDesktops by default? I don't know. If you think it is wrong please open an issue upstream or a new Fedora bug.
xmonad-0.11.1-2.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/xmonad-0.11.1-2.fc23
Hmm, is an explicit "putEnv "_JAVA_AWT_WM_NONREPARENTING=1" still needed for 0.11.1 (F23) or even F22 (0.11)? I am not able to reproduce this with 0.11.1 in fedora I think. I tried plain xmonad on F22 too (not xmonad-mate) and itweb-settings.itweb worked okay for me there - but maybe that is not sufficient test?? It's looking to me as if _JAVA_AWT_WM_NONREPARENTING=1 in releases Fedora releases?
If it is not needed I would like to revert the change (f23 testing and f24).
(In reply to Jens Petersen from comment #12) > It's looking to me as if _JAVA_AWT_WM_NONREPARENTING=1 [is redundant] in [recent] Fedora releases? Anyone able to test?
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.