I’m having a problem with a transient window returning the focus back to its parent. The application in question is a java application which I’ve read has some problems. However, it feels like there should be a solution somehow with maybe using some events to fix it.
Anyway, if I use SloppyFocus and Lenience, then this is what happens:
Application starts
User opens transient window
User does stuff with it and then closes it
<parent window regains focus but it doesn’t receive keyboard events>
If I then move the mouse outside the window and then back inside the window, it will regain the ability for my keyboard events to type into it.
If I don’t use the Lenience option, then my parent window usually doesn’t regain focus (only does so maybe 1 out of 5 times) but when it does regain focus, it will be able to receive keyboard events.
I’ve tried to see if there’s any solution for this, and it appears that some kind of FvwmEvent on the destroy_window event may be the solution, but I have yet to get something to work. Anyone have any ideas?
This is on linux, BTW. If I use this same application with KDE or mwm, it works fine. However, I don’t want to use KDE or mwm.
Is there any way to figure out what the parent of a transient window is? Then I could have an event when the window closes, it’ll switch the focus back to its parent. Switching the focus to the next or previous window doesn’t do what I need right now unless I can somehow force the parent to be either the previous or the next window.
If it is indeed a problem with JAVA, is there any solution in the JAVA code that can be done to fix it?
I’ve mucked around a bit more and have given up. I modified fvwm to add a $[w.parent.id] method which let me get the correct window id of the controlling java parent. I made sure it matched the id returned by the xprop command. However, even setting the focus using an FvwmEvent and that correct window id didn’t fix my problem. I was able to raise, lower, etc. it but setting the focus didn’t work consistantly. At this point, I guess I’ll just run without the Lenience option as that at least tells me when I don’t have input focus. That is, when the title bar doesn’t highlight, I know I don’t have keyboard focus. However, when the title bar does get highlighted, I do have keyboard focus in my app. Maybe in a few years something will happen to make this work out for me. (Either java fixing up their stuff or fvwm adding some new mode to make java apps happy) And if I REALLY need it to “work” 100% of the time, I’ll have to use mwm for now.
No, no, no… This breaks the ICCCM. What happens if the window in question is modal?
Again, Java. AWT, in fact, if you care.
See above – Java doesn’t play nicely with compliant window managers, and actually, Lenience is your friend. The problem you have is that keyboard focus is dependent on window focus. There has been more than one complaint launch against Java about this, to no avail. Most likely, thanks to sun’s bullshit policy, if it works under SunOS (OLVWM, if you will) it must be right. But make no mistake, there is nothing FVWM can or should do. Java has to fix itself first of all, then everything falls into place.