My favorites | Sign in
Project Home Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 177: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
111 people starred this issue.
Comments by non-members will not trigger notification emails to users who starred this issue.
Back to list
Status:  Fixed
Closed:  Nov 2012

Sign in to add a comment
Reported by, Apr 13, 2008
What steps will reproduce the problem?
1. run any Java application (use JDK1.6u1 or higher and xmonad with
SetWMName extension to overcome the gray rectangle bug). E.g. run Notepad
demo from demo/jfc/Stylepad directory in JDK home, like so:
java -jar $JDK_LOCATION/demo/jfc/Stylepad/Stylepad.jar
2. After starting the window doesn't get focus (that's a first example of
the problem) 
3. click inside the window, so it gets focus. If it is a Stylepad
application, you'd be able to enter text in the editor window
4. Switch to another  window on the same workspace, either using keys, or mouse
5. Switch back
6. Although the frame around the Java app becomes highlighted (meaning
xmonad thinks it has the focus), Java app doesn't seem to get the focus
(you cannot edit the text or open menus in Stylepad until you click with
your mouse into the window)

What is the expected output? What do you see instead?
Java application should get the focus after switching back to its window
from another window.

What version of the product are you using? On what operating system?
xmonad 0.7 + latest patches from the repository
Debian GNU/Linux, 2.6.24-3

Please provide any additional information below.

I've done an investigation together with Java AWT engineers and we've found
that this is a problem in xmonad, not in Java. The problem is that xmonad
ignores the WM_TAKE_FOCUS protocol which is described in the ICCCM (see

Java sets <Globally Active> model for its Frames/Dialogs, and <No Input>
model for its Windows. In both of these cases the WM shouldn't call
XSetInputFocus by itself. In the former case it should send the
WM_TAKE_FOCUS event to the window (when it decides that the toplevel window
should get the focus), in the latter case it shouldn't do anything (Java
processes all the clicks by itself).

See also the attached C file. You can compile it using the following command:
gcc -o native -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 native.c

When run, this file file prints the FocusIn/FocusOut events and also it
prints WM_TAKE_FOCUS events if they are sent. The correct behaviour of this
program in the WM is to print the message "event on frame %i:
WM_TAKE_FOCUS" (where %i is the number of frame, 0 or 1 in this program)
whenever the focus is set to its window using the WM (either using keys, or
mouse). Incorrect behaviour is when it prints only pairs of the
"FocusIn"/"FocusOut" messages.

I tried reproducing the same problem in IceWM and found that it handles the
WM_TAKE_FOCUS protocol correctly (both on this test program and on real

I attempted to fix the problem myself but for some reason the fix didn't
work. See the attached Operations.hs file which contains the fix attempt
starting with the line

    -------- WM_TAKE_FOCUS fix attempt starts here --------

If you have any questions or need any further clarification from the Java
AWT engineers, please contact me at

I consider this problem as "quite serious" (on some abstract seriousness
scale), because it ruins the xmonad using experience as well as Java
application using experience when they are used together.

2.5 KB   View   Download
22.1 KB   View   Download
Apr 14, 2008
Project Member #1
Please attach a patch in 'darcs send' format, this makes it much easier for us to see
what has been changed.
Apr 14, 2008
failed fix attempt patch is in the attachment
2.2 KB   View   Download
Apr 17, 2008
Potentially the same thing using claws-mail auto complete, and workspace switching.

1. Compose new mail, and attempt to auto complete an email address
2. Once the completion list pops up, use mod-<n> to switch to a different work space
3. The completion dialog stays raised, and only disappears when clicked on.
Nov 23, 2008
Project Member #4
Ivan's patch works for me (tested with Stylepad). Can anybody else test and confirm?
Status: Fixed
Nov 23, 2008
Project Member #5
Don’t call it fixed until it was added to the repository, otherwise the patch might
get lost.
Nov 24, 2008
I can confirm that it fixes my problems with focus in some Java apps. I didn't try
this patch before, because author said it doesn't work and already installed fluxbox
to work with those apps. :)
Mar 18, 2009
#7 pauld.mccarthy
Ivan's patch works without modification on my setup: 
 - xmonad 0.8
 - jdk 1.6.0_02
 - matlab r2008b
 - ubuntu 8.04

Thanks a heap; it's been incredibly painful for me having to focus with the mouse
Mar 19, 2009
I have had focus-related issues in netbeans 6.5 and other java applications (xmonad
0.8.1 configuration attached, Ubuntu 8.10, java-6-sun-, slightly different
issues in 32 and 64-bit versions of Ubuntu), e.g. no keyboard focus until you click
in a window. This problem meant that I found netbeans unusable under xmonad.

Applying this patch to the current darcs version of xmonad seems to have solved the
problem for me, at least in netbeans!

557 bytes   View   Download
Mar 31, 2009
Another success story: matlab (2009a) on xmonad 0.8.1.
Jun 11, 2009
This works as a logHook too. No need to patch xmonad

      logHook            = takeTopFocus >> setWMName "LG3D", -- fix java Bug

takeTopFocus = withWindowSet $ maybe (setFocusX =<< asks theRoot) takeFocusX . W.peek

atom_WM_TAKE_FOCUS      = getAtom "WM_TAKE_FOCUS"
takeFocusX w = withWindowSet $ \ws -> do
    dpy <- asks display
    wmtakef <- atom_WM_TAKE_FOCUS
    wmprot <- atom_WM_PROTOCOLS

    protocols <- io $ getWMProtocols dpy w
    when (wmtakef `elem` protocols) $ do
        io $ allocaXEvent $ \ev -> do
            setEventType ev clientMessage
            setClientMessageEvent ev w wmprot 32 wmtakef currentTime
            sendEvent dpy w False noEventMask ev

Jun 21, 2009
Here's my take at a better patch that I believe correctly implements each of the
focus models specified by ICCCM. The main difference to the previous patch posted
here is that setInputFocus is not called when the input hint is not set. I get better
results on netbeans that I did with the previous patch.
9.9 KB   View   Download
Jun 25, 2009
#12 hgabreu
Ivan's patch worked for me too.
I've tested with JDeveloper on jdk 1.6.0_14
Oct 1, 2009
Why is this not accepted over a year later?  This defect renders Netbeans, for
example, rather unusuable under XMonad, especially if you want to use the jVi plugin
with it.

This should have high priority to get into the next release.
Oct 1, 2009
Project Member #14
We've actually only had a patch that isn't labeled as a "failed attempt" for a few
months, which is one reason this hasn't seen action yet.  The second reason is that I
don't typically use Java applications, and therefore don't notice the bug.

I'll try to get to this.  However, it would certainly help if a few people could test
gereedy's patch and also make sure that it applies cleanly against xmonad head.
Owner: SpencerJanssen
Oct 2, 2009
I've just tried gereedy's patch against latest darcs.  This works fine for java
(1.6.0_16) but breaks xev: All keyboard events to the focused xev window go to the
previously focused window instead.
Oct 2, 2009
I can confirm Simon's observation.  The regression observed with xev is ugly -- still
I prefer a working Netbeans and jEdit over a working xev at this moment...

Maybe somebody with a working knowledge of the X protocol (not me) could have a
closer look.  I have a hunch we're not far away from a clean patch.

In any case, Xmonad not cooperating with Java Swing applications should be a no-no.
Oct 10, 2009
The xev problem was because I didn't handle the case where the input hint field of
WMHints wasn't set properly. This updated patchset takes care of that problem.
12.9 KB   View   Download
Oct 21, 2009
The second patch by gereedy works fine here on latest darcs xmonad: no problems with
the java stuff and xev works fine again.
Oct 21, 2009
Second patch works for me too: no keyboard problems with java applications any more.
Not sure what the problem was with xev, nor how to validate that it is fixed.
Oct 22, 2009
This patch also fixes Cellwriter (a handwriting recognition / virtual keyboard input
panel, often used on tablet PCs running linux) under xmonad.

Without this patch, the only way to get Cellwriter to send its input somewhere useful
is to doIgnore it in a manageHook. But that is a work-around at best, because it
means normal xmonad keybindings won't work any more in Cellwriter.

Oct 22, 2009
#21 hgabreu
I've tested last patch too and it worked great. Solved java and xev issues!
In my option this is a severe issue and there's no reason for not being in next release.
Oct 22, 2009
Project Member #22
This patch causes keyboard input in openoffice writer to go to the main window even
when you have the bullets and numbering formatting window open. This is useful, then
those buttons cannot be modified with the keyboard. Perhaps compliance to
WM_TAKE_FOCUS should be configurable.

xev works properly.

I'm not sure of the java focus issues: with some apps like jmemorize, you have to
occasionally click in a grouping of widgets to gain keyboard focus. On the other
hand, once the app has keyboard focus in the right area, the keyboard focus remains
after focusing other windows and workspaces using xmonad.
Labels: Component-Core Usability
Oct 23, 2009
Just to clarify the openoffice issue as described by Adam Vogt:

When a floating toolbar in openoffice gets focus all keyboard input is send to the
previously focused window.

A quick search on the openoffice issue tracker brought up which seems to suggest that
the toolbar should not get focus in the first place.

Nov 26, 2009
Project Member #24
Geoff Reedy's last patch doesn't apply cleanly against latest darcs (due to the
merging of extensible state stuff). Attached is a patch bundle including the old ones
that probably works as the old one did.
16.1 KB   View   Download
Nov 29, 2009
Latest patch works perfectly in xmonad-darcs, fixing my Cellwriter issues. Thank you so much for updating it!
Dec 7, 2009
Project Member #26
(No comment was entered for this change.)
Labels: Milestone-Release1.0
Dec 15, 2009
A similar problem with ion window manager was reported to Java:
Jan 28, 2010
Perhaps one should only keep track of the last event time because the currentEvent is
only used for getting the time? When the incoming event is non-timed just leave the
lastEventTime untouched.
Feb 3, 2010
The latest patch from vogt.adam also makes the onboard[1] application work correctly.
Also see the discussion in [2].

Feb 13, 2010
The latest patch solves the problems with focus in Matlab for me. Good work!
Feb 15, 2010
Just wanted to add that usage of Maple (another commercial Java app) benefits from
the latest patch, too. (It doesn't apply right away to the current repository, but
the conflict resolution is obvious.)
Feb 22, 2010
#32 hgabreu
patch cannot be applied in latest darcs
Sorry, but why this patch have not been applied to the repo yet?
Feb 22, 2010
Project Member #33
Here you go:
14.4 KB   View   Download
Apr 12, 2010
Any progress on this subject? I'm currently using patched darcs xmonad, but it makes
working with openoffice really hard. Is this ever going to be fixed for real?
Apr 12, 2010
You should probably patch your OpenOffice as well.

I recall reading something about focus of their toolbars being problematic and some
discussion of proposed changes.
May 21, 2010
fixes netbeans for me
May 21, 2010
Yes, this patch seems to solve problems for a lot of people. Why has it still not
made it into the repository?
May 21, 2010
Because OpenOffice is broken in such a way that it works worse with the patch applied.
May 21, 2010
I believe this patch has a bug that is only visible after several hours of having a
java application opened and working with it (e.g. netbeans), read on please.

Sometimes when running java under *patched* xmonad, after working for a while (3
hours or so) with a java application (say, netbeans) I find other applications
(especially firefox) to be very slow at gaining focus, e.g. if I switch from the java
workspace to the firefox one, it'll take about a second or so to give focus to the
firefox instance. If I close the java application then everything gets back to
normal. It gets worst as time goes by, until the java application is closed.

Has anyone experienced a similar behavior? What can I do to troubleshoot this? if I
run "top" I see X taking a lot of cpu when changing between WS. Any help will be
May 21, 2010
I've experienced the same behaviour with non-Java apps and without that patch, so it
might not be related to that patch (for me it's typically emacs + firefox).
May 25, 2010
This patch (by vogt.adam, comment 33) solved the issues I had with Java applications. 
As I do a lot of development with Java, I'd really like to see this patch included in 
the repository. Without the patch some Java applications are almost unusable.
May 29, 2010
I tried patch from vogt.adam but it isn't working. I am using mucommander, which is
written in java and when I for example do copy I cannot control copy dialog from
keyword. Even if I click on dialog with mouse I can't use keyboard - I have to click
with mouse to some form control (button, text field, etc) - then keyboard is working. 
Jun 2, 2010
I noticed that this patch also fixes another issue with Matlab. When using GUI
functions like inputdlg, without the patch the dialog doesn't seem to get focus at
all, whereas after applying the patch it works as expected.
Sep 12, 2010
patch by by vogt.adam, comment 33 works very well
Sep 15, 2010
Patch in comment 33 works for me too, applied against the latest darcs, fixing Cellwriter perfectly!
Sep 16, 2010
Will this patch ever make it into the repository / and or prebuild packages? I find it very cumbersome to patch xmonad using Ubuntu. On Gentoo it's not a problem, but Ubuntu took a lot of fiddling around for me...
Oct 7, 2010
Sorry for any ignorance revealed by this comment but...  Not used to darcs or haskell.  However, I applied the patch from Comment 33 with
darcs apply <patchname>.dpatch
Then ran Setup with configure/build/install
Then restarted xmonad (and later did a full reboot just to be sure).
I still have the following behavior in netbeans / jvi
click in editor
hit : (bring up seperate command subwindow that gets focus)
hit escape or enter (closing command window)
cursor is gone, only way back to editor is by cilcking inside it, which of course renders netbeans / jvi unusable...

A) Is this the problem the patch was supposed to solve?
B) If so, any ideas as to why it is not solved?

Jan 26, 2011
I also find this patch, or any solution for java apps ignoring focus-follows-mouse, indispensable.
Jan 26, 2011
Just so everyone is aware, Tony Morris, has packaged this up and it has been committed to XMonadContrib. 

It can be found in XMonad.Hooks.ICCCMFocus.

Jan 26, 2011
I'm using Xmonad-contrib 0.9. I cannot find  XMonad.Hooks.ICCCMFocus.

Will this be in some other version?

Jan 26, 2011
It has already been added to darcs so should be there for 0.10. 
Feb 15, 2011
@52: And how do I actually use this?
Feb 15, 2011
And should not this be enabled by default anyway?

I's been pointed out that this is part of standard the I<many Cs>M standard and that many applications are broken without the hook.
Feb 15, 2011
As stated in comment #52, it should be there for 0.10. For a temporal solution, you can use Xephyr (, with a little configuration you can "embed" it in xmonad, or use it as a "programming environment" in case you are a java developer.
Feb 21, 2011
Finally a fix for this problem!


Add import XMonad.Hooks.ICCCMFocus to the top of your xmonad.hs file. Then set logHook = takeTopFocus. Or if you got more things there like I do:

lookHook = do

Feb 21, 2011
@56: Yes! Thanks, now I got it working!
Jul 15, 2011
I discovered this issue with Intellij Idea 10.5 Community Edition on FreeBSD 8.2-STABLE. I'm looking for next release to include the solution.

# pkg_info | grep 'xmonad'
hs-xmonad-0.9.2_1   Xmonad is a minimalist and tiling window manager for X
hs-xmonad-contrib-0.9.2_1 Third party tiling algorithms, configurations and scripts t

# uname -a 
FreeBSD **** 8.2-STABLE FreeBSD 8.2-STABLE #0: Sun Jun 19 14:44:21 BST 2011     user@****:/usr/obj/usr/src/sys/GENERIC  amd64

Aug 5, 2011
Apparently this issue reappeared after upgrading to jdk7.

I'm currently using archlinux with jdk7 and it seems that I can't focus any textbox at all in Intellij Idea 10.5

If I run the same version of Intellij with jdk6 everything works fine using this patch.
Aug 10, 2011
 archlinux 64bit
 intelliJ 10.5CE _and_ jEdit editor

stopped working since the java 7 upgrade

the "logHook = takeTopFocus" workaround only helps with the first input I focus, subsequent inputs fail to get focus (i.e. menu -> new Project -> name (works) -> desc (doesn't get focus)), especially if they appear on different dialogs
Aug 11, 2011
Similar to comment #60,
on my Archlinux x64 using JRE7 I am unable to get a focus in textfields of Java apps. Example: Squirrel-SQL
Aug 19, 2011
I had the same problem of focus with java 7 and netbeans. 
I made this combination on xmonad.hs:
        , startupHook = setWMName "LG3D">> takeTopFocus
And I had luck because it works for me. :)
Aug 20, 2011
Even better!  Just startupHook = takeTopFocus solves the problem with java menus.
Aug 21, 2011
Yet it is logHook, not startupHook; otherwise application loses keyboard focus upon switching to other windows and back to it.
Aug 24, 2011
I've the same problem with java7, x64, archlinux and xmonad-darcs; while the "solutions" in @62, @63/@64 works (at least partly) for netbeans I still stuck with intellij :-( Any other options/workarounds?
Aug 25, 2011
I have the same problem with intellij and the only way I've managed to fix it so far is by having another java 6 installation and forcing intellij to use that version instead:

export IDEA_JDK=/home/vially/.apps/jdk1.6.0_26
exec /usr/share/intellij-idea-ultimate-edition/bin/ $*

However, this only works if you do not need intellij to use java7 explicitly.
Aug 30, 2011
I also had this problem with NetBeans. ICCCMFocus hook fixed the issue for me, but this was pretty hard to find. Also, why should this be a separate hook when this is a bug with Xmonad? Also is xmonad still actively developed? It looks like the last release was over 2 years ago.
Sep 2, 2011
Strangely, whilst the patch fixed the Cellwriter problem (comment 20), the ICCCMFocus takeTopFocus hook does not. And the patch doesn't apply to the latest Darcs version.

Anyone know how to get Cellwriter working again with the recent Darcs versions of Xmonad?
Sep 2, 2011
This is possibly because the ICCMFocus hook uses currentTime as the client message data. The ICCM spec says that the timestamp should not be currentTime but a real timestamp, presumably the timestamp of the event causing the focus message to be sent. As far as I can tell the main difference from the hook and my patch is that my patch tracks the timestamp of events so that the message field can be properly sent. I think it ought to be possible to add that behavior by adding an event hook that stores the last event time in some extensible state.
Sep 2, 2011
Actually, I missed the latest version of the patch from Comment 33. I just tried it, and that one not only applies cleanly against the latest Darcs, but *also* fixes the cellwriter behaviour.

Evidence for your timestamp theory, perhaps?
Sep 2, 2011
Confirmed: patch from comment 33 fixes intellij/jdk7 problem as well (as opposed to the original patch and ICCCMFocus hook).
Sep 6, 2011
How is a dpatch applied to a source tarball?

I don't see any option for doing so, darcs refuses to apply since I have only the source, not the repo.
Sep 6, 2011
Project Member #73
dpatches cannot be applied to non-repositories, so "darcs get" the repository before trying to apply the patch.
Sep 7, 2011
Thanks Daniel!

Now, after applying the patch from comment #33 to Xmonad-darcs, Xmonad itself compiles fine, but Xmonad-contrib-darcs no longer does:

    Ambiguous occurrence `atom_WM_TAKE_FOCUS'
    It could refer to either `XMonad.Hooks.ICCCMFocus.atom_WM_TAKE_FOCUS',
                             defined at XMonad/Hooks/ICCCMFocus.hs:34:1
                          or `XMonad.atom_WM_TAKE_FOCUS',
                             imported from XMonad at XMonad/Hooks/ICCCMFocus.hs:27:1-13
Sep 7, 2011
The dpatch and the hook in Xmonad-contrib both define the same function names etc., causing the name conflict you're seeing if you try to use both at the same time. Thus you can't compile the ICCCMFocus module if you want to use the implementation from the dpatch.

Someone can probably suggest a better way of doing this, but as a quick hack I just deleted the XMonad.Hooks.ICCCMFocus line from the xmonad-contrib.cabal file to get it to compile without error after applying the dpatch.
Sep 7, 2011
Project Member #77
It's probably better to just delete the definition of atom_WM_TAKE_FOCUS from ICCCMFocus.hs. Bonus points if you double check that it's the same definition as the one in the patch:

Sep 13, 2011
Project Member #78
The atom definition is indeed the same in the Core/Main/Operations version and the contrib one.

A quick look at the diffs with meld and reading through Hooks.ICCCMFocus leaves me thinking that it wouldn't be too difficult to implement in contrib with Extensible State. This has the advantage of making it easier for more people to use, test and (if necessary) modify the focus tracking code. It could easily be "forked" by modifying Hooks.ICCMFocus in ~/.xmonad/lib rather than having to overcome the barrier to core changes. And of course it can be used by people who want it and ignored by those that don't.

On the other hand, disadvantages are: Java and alternative input method users have been grumpy for years that this doesn't work out of the box with core xmonad. It's cleaner implemented in core, and a correct implementation belongs there.

For a visual overview of the differences, see

For the primary change in Operations and brief summary of Core and Main changes see the patched version of setFocusX at 

I'd like to see Hooks.ICCCMFocus marked transitional with it fully implementing this patch, or deprecated with a "signed-off" core implementation committed instead. No promises, but if no-one else is motivated to update H.ICCCMFocus, I'll attempt to get something together during next month or so. It's about time to make this easy to test, given that theoretically 0.10/1.0 is overdue by quite a while already.

Any X and ICCCM experts have opinions one way or the other?

Sep 13, 2011
Project Member #79
xmonad is not an X11 window manager if it doesn't implement ICCCM requirements.  This belongs in core, regardless of "purity" arguments.
Sep 13, 2011
I took a look at if this could be done through extensible state and a modification of the logHook in Hooks.ICCCMFocus and my opinion is that it cannot.

There are a few problems with the logHook as is:

 - It uses currentTime as the event time, violating the ICCCM
 - It sends a WM_TAKE_FOCUS client message every time the logHook is run

Problems with the out-of-core approach in general are:

 - No way to connect a focus change to the event that caused it. The closest possibility is to have an eventHook that stores the event in some extensible state or in an IORef cell. The problem is there is no way to clear it once event processing has finished.
 - The logHook is the only reasonable place to put the sending of the WM_TAKE_FOCUS client message, but the logHook is called many more times than the focus is changed. It might be sufficient to remember the focused window from the last invocation and send when it's different, but it's still quite hackish.

The in-core solution as-is is found wanting as well:

 - When a window refuses to take focus (like many on-screen keyboards) it's not possible to manage the window. XMonad's management focus is tied directly to input focus.

I agree with #79 that xmonad should take care to implement the ICCCM properly without needing any contrib modules.
Dec 4, 2011
I can confirm that the solution from #56 only works with Java 6, not 7.

Running XMonad 0.10 on Ubuntu 11.10 with IntelliJ IDEA.
Dec 9, 2011
I'm running IntelliJ IDEA with Java 7, and got the same problem
Jan 6, 2012
With IntelliJ IDEA - when you type package name and use dot symbol at the end - then IntelliJ complains about wrong package name, and package input becomes "selected". So if you will type something - then the content of input will be replaced.

I verified this behavior under different window manager (fluxbox) - and there is no such problem, so it's not OS/JDK/IDE issue.

Can somebody please advice?
70.2 KB   View   Download
Jan 7, 2012
I tried to solve the problem with sending of duplicate focus events to IDEA with patched version of XMonad.Hooks.ICCCMFocus (see attached). Now two focus events are not dispatched to same window twice, which seems to be good, however in IDEA on wrong package name the text input box doesn't gain focus automatically. So perhaps this solution is not really helpful for me, and potentially wrong.

Can somebody please advice something better?
1.9 KB   View   Download
Jun 26, 2012
Arch Linux here. With jre7-openjdk, cannot focus text fields, mouse or not, when using XMonad, but can when using other WMs. As per FAQ, set _JAVA_AWT_WM_NONREPARENTING to 1, but the problem persists.
Jun 26, 2012
same problems still here with no workaround working. This is really getting a pitty not being able to use intellij and squirrl :-(
Jun 26, 2012
Well, this problem ist actually solved, as the patch from Mr. Vogt (see comment #33) fixes my problems with Java-Apps (incl. Squirrel-SQL, ...). The problem is that this patch hasn't been included in the official distributions (wasn't applied to xmonad-darcs) yet, for whatever reason. This is a real pitty.

However, if you are on Arch-Linux, you can find builds of xmonad and xmonad-contrib in the AUR-repository that include this patch and fix the Java-focus problems.

Not sure whom is to bug so this patch gets into mainline.
Jun 27, 2012
Is it possible to get this darcs patch in "normal" form for patching? Want to try it out with recent build
Jun 27, 2012
> Well, this problem ist actually solved, as the patch from Mr. Vogt (see comment #33) fixes my problems with Java-Apps
No no no... It's works only for java 6(i tried openjdk/openjre 6), but not for java 7.
Jun 27, 2012
btw, I would really like to know which aur packages you mean; the default xmonad-darcs repos don't have a fix :-(
Jun 27, 2012
> I would really like to know which aur packages
xmonad-darcs has a specially crafted PKGBUILD in the comments that basically just applies this patch. However, as noted, it doesn't work with the latest JRE
Jun 27, 2012
> Is it possible to get this darcs patch in "normal" form for patching?
> Want to try it out with recent build

Take the patch from comment #33 and apply it on the latest darcs-sources of xmonad.

Also, in xmonad-contrib darcs you need to remove the references to 'XMonad.Hooks.ICCCMFocus' from the cabal file, like so:
$ sed -i -e '/XMonad.Hooks.ICCCMFocus/d' xmonad-contrib.cabal

Then make/compile both and (most?) of your Java-problems should be gone (worked for me).

Jun 27, 2012
> No no no... It's works only for java 6(i tried openjdk/openjre 6), but
> not for java 7.

It works for me using this JVM:

$ java -version
java version "1.7.0_05-icedtea"
OpenJDK Runtime Environment (IcedTea7 2.2.1) (ArchLinux build 7.u5_2.2.1-1-x86_64)
OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)

Jun 27, 2012
haha, THX A TON claus! This really does the job :-) Why isn't the patch applied by now?
Aug 28, 2012
It doesn't seem to work for Oracle jdk7. I had to follow this guide to get it to work for jdk6: And I have to use a separate machine for anything that requires java 7.

It's too bad this hasn't been fixed and works in every other wm I've tried (e.g. awesome).
Aug 28, 2012
For anyone who isn't very familiar with darcs and had to go digging around to figure out how to apply the patch, I created the following gist:
Aug 29, 2012
Running the code from GIST produces xmonad instance which doesn't work with IntelliJ IDEA. I see white screen and it doesn't repaint or change when I switch to another workspace and back.
Aug 29, 2012
> Running the code from GIST produces xmonad instance which doesn't work with IntelliJ > IDEA. I see white screen and it doesn't repaint or change when I switch to another
> workspace and back.

Do you have 'setWMName "LG3D"' in your startuphook somewhere in your xmonad.hs configuration?
I think you still need this in addition to the patch to make Java-apps work.
Aug 29, 2012
Yes, I do. I recompiled xmonad again with the patch applied, IDEA Window showed up, however keyboard focus is lost after switching between workspaces.

Without the patch everything works well.
Aug 29, 2012
I experience the same focus problems both with this patch and without it.
Aug 29, 2012
Ignore my previous comment, #94 works with Oracle jdk7 and Intellij. I'm not sure what changed for me. I did update to the most recent jd7 (1.7.0_06). It's possible I was simply doing something stupid.
Aug 29, 2012
James, would you mind to post your xmonad setup?
Aug 29, 2012
Re #99, I'm sorry its not working for you. RubyMine works for me, which is based off of IntelliJ. I'm using java version 1.6.0_34, and my xmonad file is at

You'll notice that I am setting the window name to LG3D, as recommended by #100. Hope this helps.
Aug 29, 2012
> James, would you mind to post your xmonad setup?

See attached xmonad.hs. I installed xmonad and XMonadContrib directly from a darcs checkout. Here's the steps I took (assumes ghci, cabal, and darcs installed).

  darcs get
  cd xmonad && darcs apply ~/Downloads/track-currently-processing-event.dpatch # from comment 33
  cabal install
  cd .. && darcs get
  cd XMonadContrib && sed -i -e '/XMonad.Hooks.ICCCMFocus/d' xmonad-contrib.cabal
  cabal install

I confirmed it by running xmonad --recompile with the old "import XMonad.Hooks.ICCCMFocus" line in my xmonad.hs - it should error. Remove the import and 'logHook = takeTopFocus' and it should work.
9.9 KB   View   Download
Aug 29, 2012
Looks like problems with focus and jdk6 could be solve by removing taffybar logHook though idea with jdk7 does not get keyboard focus at all
Aug 29, 2012
Using "loghook = dbusLog client >> takeTopFocus" does the trick for JDK6 but no success with JDK7
Sep 6, 2012
I confirm, it works here aswell with java 1.7.0_04-b20 on a quantal ubuntu, 64 bits.
Sep 8, 2012
Too bad, this is still an issue on Arch Linux by 09.2012 and the AUR xmonad-darcs doesn't build (issue with fakeroot). Anyone another workaround or is JDK6 the only solution? 
Sep 25, 2012
I can confirm that the contrib version doesn't work for me on Java 7, but works on 6. I'm running 64-bit Precise, and the output of java -version is:
(For Java 7)
java version "1.7.0_07"
OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2a-0ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

(For Java 6)
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.4) (6b24-1.11.4-1ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
Oct 1, 2012
I confirm that the patch from comment 33 fixed the focus problem with Java apps for me. I'm using:

java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) Server VM (build 23.3-b01, mixed mode)

Oct 6, 2012
Can we get something committed? This issue has been open for over 4 years, and XMonad is still unusable with many Java applications.
Oct 11, 2012
I'm also quite +1 for applying patch 33 since it perfectly fix all problems for me!
Oct 28, 2012
Please apply the patch. XMonad is unusable without it.
Nov 2, 2012
Please apply this patch. Seriously. 
Nov 5, 2012
Seriously. Please apply this patch. 
Nov 8, 2012
Project Member #120
 Issue 519  has been merged into this issue.
Nov 16, 2012
Apparently the patch from comment #33 was merged. So if you pull the current xmonad and xmonad-contrib versions from darcs everything should be fixed.
Just make sure to remove the logHook = takeTopFocus and the old import XMonad.Hooks.ICCCMFocus which is now deprecated.

I've tested it on Archlinux with openjdk7 and no issues so far.
Nov 16, 2012
Project Member #122
There's no real reason to remove takeTopFocus since the code in contrib has been changed so to just do `setWMName "LG3D"'. The DEPRECATED pragma is to let people know who might not necessarily check here.
Status: Fixed
Nov 16, 2012
Gentoo, latest sources from darcs repo, tested SunJDK 1.6 & Oracle JDK 1.7 using IDEA (10.5 and 11) - works only with takeTopFocus in logHook and only for 1.6.
takeTopFocus though hase some othe nasty consequences (e.g. sometimes Libre Office dialog boxes make xmonad hang)
Nov 16, 2012
Sorry, that was a false alarm (it happened to be not the latest sources) new tests show that everything works OK for me
Dec 4, 2012
Can somebody now summarize the status? I really want to switch back to xmonad but I want to know if the java application I have to use work.

I also want to know in which RELEASE of xmonad (no, I won't build a specific darcs version, I use linux because it has a packaging system that does all the update mess for me) the fix will be present and when that will be available.
Dec 4, 2012
For me, last version from darcs just works well. Don't know about release plans...
Dec 4, 2012
Project Member #127
losinski.j, If I were to `cabal upload' now, it's possible that you might still need to add to the logHook `setWMName "LG3D"' to get your java app to work.
May 6, 2013
Correct me if wrong, but cabal installing xmonad 0.11 (and xmonad-contrib) + adding LG3D to logHook (not tested if needed or not) seems to fix it for JDK7.
May 6, 2013
Project Member #129
startupHook, not logHook. Although if you use EwmhDesktops, see about how to make them coexist.
Sign in to add a comment

Powered by Google Project Hosting