stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[STUMP] Workaround for misbehaving focus in Java applications


From: Elias Mårtenson
Subject: [STUMP] Workaround for misbehaving focus in Java applications
Date: Tue, 27 Dec 2016 17:37:53 +0800

Since starting to use StumpWM, I've noticed an issue with IntelliJ IDEA sometimes losing focus in some weird way. What happens is that IDEA has focus, some keypresses work, but the cursor isn't visible and I can't type text into the edit buffers.

I finally came up with a workaround that works for IDEA, but I've been told this is an issue for all Java applications, so perhaps it should be adopted as a more general feature?

Here's the code I've added to my $HOME/.stumpwm.d/init.lisp to fix this:

    (defun handle-focus-window-update (win cw)
      (declare (ignore cw))
      (when (and (member :WM_TAKE_FOCUS (xlib:wm-protocols (window-xwin win)) :test #'eq)
                 (equal (window-class win) "jetbrains-idea")
                 (eq (window-type win) :normal))
        (stumpwm::send-client-message win :WM_PROTOCOLS
                                      (xlib:intern-atom *display* :WM_TAKE_FOCUS)
                                      0)))

    (add-hook stumpwm:*focus-window-hook* 'handle-focus-window-update)

Would it be correct to always send the :WM_TAKE_FOCUS message to any client that supports the message? I've read the ICCCM spec, and it's still not entirely clear to me. In fact, I'm not sure I understand what the purpose of the message is in the first place, and only Java seems to behave the way it does.

Also, my current hack ends up sending the message twice (once from my code, and once from StumpWM itself) when switching frames using FNEXT. That doesn't seem to have any negative impact though, but a proper solution should of course not do that.

Regards,
Elias



reply via email to

[Prev in Thread] Current Thread [Next in Thread]