On Fri, Jul 11, 2003 at 02:03:19AM +0300, Tuomo Valkonen wrote: > On Thu, Jul 10, 2003 at 09:09:01AM +0200, Xavier Maillard wrote: > > I did it using a 3rd party tool (xbindkey) but can't do the same under > > Ion any reason not to be able too ?? > > Does xbindkey execute the program when the key is released? It appears > to me that the x locking programs don't like the fact that Ion may still > have the keyboard grabbed (implicitly by X server) if the key has not > been released before the program wants to grab the keyboard. Executing > e.g. "xterm" from a ccroll lock binding works just fine (except for the > annoying led). "Xlock" works half of the time (takes sometimes longer > to load) while "xtrlock" is always too fast. > > A kludge around this problem is to write a short shell script that > sleeps for, say, a second and then executes the locking program. > (I might add a krelease action some time in the future; it shouldn't > be too much extra code..)
I was experimenting with the new menu module and discovered that xlock randomly fails even when executed from a menu that doesn't grab anything. I don't know what's really causing the problem then -- X just complains of the client not being authorised to connect -- but for some reason, calling XSync() before fork()ing seems to remove the problem. Index: exec.c =================================================================== RCS file: /share/cvsrepos/ion/ioncore/exec.c,v retrieving revision 1.13 diff -r1.13 exec.c 72a73,74 > XSync(wglobal.dpy, False); > -- Tuomo
