Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.windows.x Subject: TWM (was Re: Intercepting key events by a window manager) Message-ID: <20667@news.Think.COM> Date: 24 May 89 19:24:02 GMT References: <1265@imelda.Solbourne.COM> Sender: news@Think.COM Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin) Distribution: comp Organization: Thinking Machines Corporation, Cambridge, MA Lines: 31 In article <1265@imelda.Solbourne.COM> toml@Solbourne.COM (Tom LaStrange) writes: >If I understand you right, twm allows you to do such a thing. You >could put something like > > "F1" = : window : f.raise > >in your .twmrc file, and when the F1 key is pressed while the pointer >is in the client window, the window will be raised. It's not dumb, >it's VERY useful, I couldn't get by without it. But it's not as useful as it could be. The documentation implies that the context field is the location of the pointer, but it actually uses the current input focus. If you use anything other than follow-pointer focus, these are very different. For instance, if you set the focus to a window you can't make use of a key bound to f.focus in order to change the focus. While on the subject, I'd like to warn people: don't bind f.twmrc to a key in TWM! Executing this key generally caused TWM to die with a segmentation violation. It uses a linked list to hold the key bindings, and (for some reason) continues scanning down the list after executing the binding. However, after executing f.twmrc the list it was scanning has been freed, and the memory may have been reused for other things, so it dereferences garbage pointers. The menu code is organized differently and doesn't have this problem. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar