RXVT-Unicode Issue in Client/Daemon Mode about icewm HOT 11 CLOSED

Good work on the bisect. Is there a reason that you don't just put

ActivateJava7FocusHack 0

in your preferences file? Maybe the default should be false instead of true?

from icewm.

Setting "ActivateJava7FocusHack=0" in the preferences file fixes the issue in RXVT-Unicode terminals. For some reason, I read that commit message to be referring to a hard-coded setting for that variable, and it didn't strike me that it was an option in the preferences file.

I'm reluctant to weigh in on the proper default since I'm unfamiliar with the Java(7) issue that is addressed by this patch.

But it would be nice if it was somehow more obvious to either the Java(7) users or the RXVT-Unicode users that problems they encounter may be related to this setting.

Thanks for the feedback.

from icewm.

Is this issue resolved?

from icewm.

Can you point me to a Java(7) application that requires this patch (or perhaps all Java(7) apps require this, I'm not familiar with the issue). I'd like to poke around at trying for a real fix if I can find a way to replicate the original issue.

from icewm.

FYI: Another application broken by the Java(7) focus hack is "display" (part of the imagemagick 6.9.0.3 package). In most cases the keyboard focus hotkeys seem to be delivered to some other window even when the image window visually has focus (according to the border). Occasionally I stumble over a state where key press events are handled properly, but I haven't narrrowed down exactly when/how.

Setting ActivateJava7FocusHack=0 fixes it. (Or actually, there is still a long-standing slight annoyance where when I hit the spacebar to go to the "next" image, some other window often gets focus until I move the mouse out and back in again. [I've tried to configure it as closely to pure "focus follows mouse" as I can get.] But at least focus is visually consistent with the border, it is much easier to get focus back where I want it than with the java hack enabled, and I suspect this annoyance is not really related to the java hack.)

@mharder: Maybe zstegi at the gmail dot com host (the author of the hack) would know more? Also, based on commit comments, commit d3b00cc apparently also involved some kind of java focus issue, but I have no idea how closely it is related.

from icewm.

I sent an email to zstegi a week ago.

Hopefully, we'll hear something back.

I've been running iced-tea-7.2.5.5 with vuze and imule (two java based p2p tools). I have ActivateJava7FocusHack=0, and can't discern any issues with focus.

Although, I'm not sure if perhaps this is Oracle Java specific. If anybody has any other Java applications they'd like me to test, let me know.

Otherwise, if we don't hear back from zstegi, and we don't run across any Java applications that trigger the issue, then maybe switching the default for this parameter to disabled would a good way to close this issue.

from icewm.

Are you using click-to-focus? Most focus problems arise when doing strict click-to-focus.

from icewm.

Except for the ActivateJava7FocusHack parameter, all my other Focus settings for IceWM are the defaults. So, I should be running with ClickToFocus=1, and everything seems to be operating that way.

I gave vuze an especially long workout, including switching windows with the mouse.

from icewm.

I think we should just go ahead and change the default to 0. I wanted to cut another release because things have been stable for about a month.

from icewm.

That would be OK with me.

Let me know if you here any reports of that causing problems, and I'll try to replicate it locally.

from icewm.

Default ActivateJava7FocusHack now set to false (0).

from icewm.