pop-up windows do not get keyboard focus reliably
Brought to you by:
dannybackx
Menu
▾
▴
#32 pop-up windows do not get keyboard focus reliably
Hi again... good to have some life back in lesstif. I actually installed the 0.95.2 relase, but I have one serious regression from my old hacked version of lesstif (http://sobukus.de/lesstif/lesstif-patchwork).
The issue is that with nedit, quite often the window popped up after Ctrl+F (search dialog) or Ctrl+L (goto line dialog) does not have keyboard focus. Usually I am able to give it focus by clicking on the main window with the mouse and then on the dialog window. Changing focus via window manager keyboad shortcuts does not work. And sometimes I have to close the dialog and try again.
My window manager is fluxbox, if that is relevant.
Needless to say, this is very annoying. I used to apply this reverting patch:
http://sobukus.de/lesstif/lesstif-patchwork/patches/041_lesstif-cvs-20090312-shortcut-focus.patch
That fixed the issue at the cost of a delay before the dialog opens after pressing the shortcut. While this is a clear degradation in comparison to "real" motif (speaking of the system motif I experience on a solaris box), it at least ensures that when the window pops up and appears to have focus, it indeed gets the keyboard input I give.
Of course I'd appreciate a better fix that yields fast reaction and proper keyboard input focus, but in absence of that, I strongly recommend integrating that patch to stop the nasty defect.
Bootnote: I am reporting this in the hope to have the released lesstif more workable, but further engagement from my side towards lesstif (debugging and hacking) is going to be very limited, as nedit, about the only app that I seriously need lesstif for, is not going anywhere with development and I am going to look for another editor that at least supports unicode in the year 2009 ...
I would really like somebody with some proper knowledge of c code to have a look, but I will have a look at it myself and if reasonable, I will apply your patch. It is indeed reported at several locations. I won't be able to come up with a snappy new code thou.
Well, when you look at the concerned lines, the comments placed there by people long before our time... they didn't understand the code, neither:-/ Or they had trouble understanding what the Toolkit should do.
All I can say is that I was able to use my patched snapshot of lesstif without bigger issues for quite some time. Dialog popup on hotkey was slow, but reliable. What I am not totally sure about is if the clipboard worked properly... nowadays, with 0.95.2, I somtimes experience the problem of different nedit instances managing to lockup the clipboard. Copy/paste only working after closing all instances and restarting a new nedit. I wonder if one of the patches I used fixed that, too... maybe you could have a look at my patchset and see if your current code misses one?
I am trying to investigate the copy/paste issue, which is really tagged with FIXME all over the place, but don't expect results soon. Are you using a KDE environment by the way? Since 4.x the copy/paste issue seems to have gone bad. There is an other bug about that thou, which is mainly triggered by klipper, the clipboard manager.
Are you using all the 6 patches now with 0.95.2?
Just for the record, we are discussing here the changes in commit 1.102 and 1.107 to Manager.c when it was still in the Xm tree. It is discussed in bug #472493. Going to bed now.
https://sourceforge.net/tracker/index.php?func=detail&aid=472493&group_id=8596&atid=108596
I'm not using KDE... well, I use some KDE apps, but not the environment as such.
Also, I don't use any of the patches, I'm on vanilla 0.95.2 . So all patches are candidates unless they're already included (at least the ESC-menu crash has been fixed).
I seem to be able to choose when this bug is triggered. When my mouse is over the nedit window, pressing Ctrl-f everything works as it should. When my mouse is outside the nedit window, pressing Ctrl-f results in a find window without focus. Could you verify?
As a result (don't know why yet) the next key-presses are passed as if Ctrl is pressed in combination with the key you really press.
From the Solutions to Common Problems (nedit help page 40):
P: Dialogs don't automatically get keyboard focus when they pop up.
S: Most X Window managers allow you to choose between two categories of keyboard focus models: pointer focus, and explicit focus. Pointer focus means that as you move the mouse around the screen, the window under the mouse automatically gets the keyboard focus. NEdit users who use this focus model should set "Popups Under Pointer" in the Default Settings sub menu of the preferences menu in NEdit. Users with the explicit focus model, in some cases, may have problems with certain dialogs, such as Find and Replace. In MWM this is caused by the mwm resource startupKeyFocus being set to False (generally a bad choice for explicit focus users). NCDwm users should use the focus model "click" instead of "explicit", again, unless you have set it that way to correct specific problems, this is the appropriate setting for most explicit focus users.
Seems like this issue is related (maybe not 100%). I haven't figured out how any of these things get set in the windows manager, but changing the respective nedit option doesn't help me.
The setting in nedit doesn't help the focus. What it does for me is to determine if the popup pops up over the nedit window or wherever on the screen the mouse cursor hovers.
But your observation with the cursor being over the nedit window nails it: When cursor over nedit, the popup has keyboard focus, if cursor outside, then not.
Plus, the nedit window totally has lost focus after opening the popup, also after closing it using the mouse, until I clicked into the nedit window again.
In the mean time I am convinced that the patch is wrong. In my simple test NEdit effectively only uses the KeyPress event, which with the patch we would mask with KeyReleaseMask . However other programs do rely on proper masking of the eventType. (See the other bug I all ready mentioned).
I am looking deeper into this, it has to do with the focus handling, but this seems not the proper place to solve it. (Maybe patching NEdit where they use the is even better and it still might work for you).
I have found an other way to prevent this bug. Mind you, I have not tested on it's implications on other nedit functionality or that of other programs, but it gives insight where things are going weird. I'll attach a diff. The main change is in Vendor.c, which adds the KeyReleaseMask to any new widget, while the change in TravAct is mainly to catch the the KeyRelease event from executing new code. I found that also ClientMessage events were triggering execution of _XmTrackShellFocus, which is probably not correct, but might be unharmful.
Again, I don't think this is the proper way, but maybe triggers others to help searching where it really goes wrong.
Alternative patch to prevent NEdit bug.
Hmm, slight mistake during that patch creation: of course the code should not be commented out ;)